Markus Fischer wrote:
It is not publicly exposed with ZEND_API(). I can't test
right now, but maybe just need to modify the zend_compile.h
file and prepend the prototype definition with ZEND_API ?
Yes, prefixing the prototype with ZEND_API did the trick.
Andi, Zeev, is this
On Fri, 2002-02-08 at 10:55, Yasuo Ohgaki wrote:
Andi Gutmans wrote:
At 07:58 AM 2/7/2002 +0100, Stig S. Bakken wrote:
After careful consideration on the CS issue I must say I agree with John
here. The _only_ case where I feel CS is a problem, is when dealing
with other environments.
On Fri, 2002-02-08 at 13:38, Yasuo Ohgaki wrote:
Andi Gutmans wrote:
At 09:20 PM 2/8/2002 +0900, Yasuo Ohgaki wrote:
Andi Gutmans wrote:
Name space BC problem is bad, since script may misbehave
without proper error message where to fix.
It's a bad BC problem since it's harder to
But historically, tabs were are also rendered on screen as 8 spaces.
This is no longer true, since tabs are often 4 spaces by default. And
for this very reason, today it is better to use spaces because that is
the _only_ way to format code so it looks the same in less, Emacs, joe,
vi, MSVC, Zend
On Tue, 2002-02-05 at 20:41, Andi Gutmans wrote:
At 05:19 PM 2/5/2002 +, James Cox wrote:
Guys,
have we ever decided on this? in our code do we go for tabs or spaces? Is
there a style guide anywhere on this?
[4] When indenting, use the tab character. A tab is expected to represent
On Fri, 2002-02-08 at 14:14, Andi Gutmans wrote:
At 01:42 PM 2/8/2002 +0100, Stig S. Bakken wrote:
On Fri, 2002-02-08 at 13:38, Yasuo Ohgaki wrote:
Andi Gutmans wrote:
At 09:20 PM 2/8/2002 +0900, Yasuo Ohgaki wrote:
Andi Gutmans wrote:
Name space BC problem is bad, since
After careful consideration on the CS issue I must say I agree with John
here. The _only_ case where I feel CS is a problem, is when dealing
with other environments. But the price for changing this today is
simply too high. It should have been done in PHP 3.0. We have other BC
issues to soak
Because PHP has gotten about a million more users since then?
- Stig
On Thu, 2002-02-07 at 00:57, Jason Greene wrote:
If everyone has been able to adapt to case sensitive variable names, why
can they not adapt to case sensitive function names?
-Jason
On Wed, 2002-02-06 at 09:01, John
On Fri, 2002-02-08 at 14:30, Andi Gutmans wrote:
At 02:20 PM 2/8/2002 +0100, Stig S. Bakken wrote:
On Fri, 2002-02-08 at 14:14, Andi Gutmans wrote:
At 01:42 PM 2/8/2002 +0100, Stig S. Bakken wrote:
On Fri, 2002-02-08 at 13:38, Yasuo Ohgaki wrote:
Andi Gutmans wrote:
At 09:20 PM
On Tue, 2002-02-05 at 10:36, Hartmut Holzgraefe wrote:
[EMAIL PROTECTED] wrote:
We have been down this road before. There is a reasonable expectation that
extensions may differ subtly from extension to extension. I see no need to
fork my source for 4.0.x and 4.1.x compatibility when it is
Yes, someone banned your email address from lists.php.net (fixed now).
Personally, I find it completely unacceptable that someone goes ahead
just banning people just like that. On behalf of the PHP Group, I would
like to offer you an apology for this.
- Stig
On Tue, 2002-02-05 at 01:42,
Yes, this is going to be a problem.
I have thought one a way of dealing with it. Let people declare in
their code that major version of PHP they have written their code for,
and issue possible ambigous context warnings unless it's declared
written for PHP 5. For example, the code:
function
On Thu, 2002-02-07 at 07:17, [EMAIL PROTECTED] wrote:
On Thu, 7 Feb 2002, Markus Fischer wrote:
me. I think it would really confuse people. I suggest adding another
function. It should probably be only enabled in debug builds because the
end user shouldn't be worrying about refcounts.
On Wed, 2002-02-06 at 22:36, Jani Taskinen wrote:
Many scripts will break anyway if you update to PHP 5..
+1 (still) for case-sensitivity which would make the language
more conistent. Or if this is ruled out, then let's make all
variables and constants case-insensitive too. It is so
Stig S. Bakken wrote:
Well, shouldn't Mark, who maintains the code in question, be the one to
decide whether a couple of extra ifdefs makes his code unmaintainable?
Well, needs msession a ''prime time seat'' in /php4/ext/, or wouldn't
we all be better off putting it into /pear/?
--
On Thu, Feb 07, 2002 at 11:21:26PM +0100, Stig Venaas wrote:
On Thu, Feb 07, 2002 at 12:42:29AM +0100, marc wrote:
I just left it with the new sizeof, but there may be side-effects?
It's okay as long as you don't have IPv6, 95/98 doesn't.
I've now committed a proper fix with no
Enjoy!
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
the PHP SRM extension (module php_srm) has been moved from cvs.vl-srm.net
to cvs.php.net under php4/ext/srm. The SAPI module and Daemon will remain
on cvs.vl-srm.net.
regards,
Derick
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
Zeev Suraski wrote:
Enjoy!
Forgot TSRM? :-)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe,
Zeev Suraski wrote:
Enjoy!
TSRM seems to be missing.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
PHP Development Mailing List http://www.php.net/
To
Sebastian Bergmann wrote:
Zeev Suraski wrote:
Enjoy!
TSRM seems to be missing.
It seems that my ISP's SMTP lagged, sorry for the dupe post.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift:
Hi,
On Sun, 10 Feb 2002 15:50:34 +0100 (CET)
Derick Rethans [EMAIL PROTECTED] wrote:
the PHP SRM extension (module php_srm) has been moved from
cvs.vl-srm.net
to cvs.php.net under php4/ext/srm. The SAPI module and Daemon will
remain
on cvs.vl-srm.net.
isn't PEAR/PECL more suitable?
Jan
--
At 09:21 AM 2/10/2002 +0100, Sebastian Bergmann wrote:
Markus Fischer wrote:
It is not publicly exposed with ZEND_API(). I can't test
right now, but maybe just need to modify the zend_compile.h
file and prepend the prototype definition with ZEND_API ?
Yes, prefixing the
On Sun, Feb 10, 2002 at 12:20:55PM +0100, Sebastian Bergmann wrote:
Stig S. Bakken wrote:
Well, shouldn't Mark, who maintains the code in question, be the one to
decide whether a couple of extra ifdefs makes his code unmaintainable?
Well, needs msession a ''prime time seat'' in
I think the issue is not compatibility with external libraries but
with previous versions of the engine. IMHO, there is no reason for
a module in the HEAD branch to be compatible with older versions of
PHP. In the case of MySQL and GD, the ifdefs are used to maintain
compatibility with the
[ext/ftp]
I just left it with the new sizeof, but there may be side-effects?
It's okay as long as you don't have IPv6, 95/98 doesn't.
I've now committed a proper fix with no side-effects... There
might be other similar issues on 95/98 that I'm not aware of.
The patch looks good, I'll test
Stig S. Bakken wrote:
Well, shouldn't Mark, who maintains the code in question, be the one
to decide whether a couple of extra ifdefs makes his code
unmaintainable?
Well, needs msession a ''prime time seat'' in /php4/ext/, or wouldn't
we all be better off putting it into /pear/?
That
Learning
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
On 10 Feb 2002 18:16:01 -
softcureinc [EMAIL PROTECTED] wrote:
Learning
you do not nead a CVS account for learning PHP or the development of PHP
Jan
--
Q: Thank Jan? A: http://geschenke.an.dasmoped.net/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
I think the issue is not compatibility with external libraries but with
previous versions of the engine. IMHO, there is no reason for a module
in the HEAD branch to be compatible with older versions of PHP. In the
case of MySQL and GD, the ifdefs are used to maintain compatibility
with the
Mark:
Don't get me wrong, I have looked into msession, and it does indeed look
useful to the PHP community as a whole. It just doesn't make sense to
_me_ that backwards compatibility is being maintained to older versions
of PHP from the HEAD development branch. I am not saying remove your
Adam Dickmeiss wrote:
We could throw mysql and gd away - they have more ifdefs! (pear is
not a garbage can. If it is treated as such, nobody will move).
PEAR / PECL is certainly no garbage can. Also, nobody wants to throw
away the msession extension. It's just that we decided some time
Stig S. Bakken wrote:
Because PHP has gotten about a million more users since then?
Good point.
I also think less number of impacts for existing code is preferred.
Since many people believe ini option for case sensitivity will lead
bad compatibility problem like register_globals, I might
Sebastian Bergmann wrote:
Adam Dickmeiss wrote:
We could throw mysql and gd away - they have more ifdefs! (pear is
not a garbage can. If it is treated as such, nobody will move).
PEAR / PECL is certainly no garbage can. Also, nobody wants to throw
away the msession extension. It's
From php-general.
2th of Feb. is odd, isn't?
Someone may want to take a look at it.
--
Yasuo Ohgaki
Laserjetter wrote:
I've just realised that the suffix for the day of the month is correct for
today (1013336429) but it isn't the 2nd today and my clock is set right.
Anyone got any ideas?
I think it cool that discussions travel between php-dev, php-cvs,
pear-dev, and the zend-engin2 mailing lists, but I'd like to ask
all of you to take the time to trim the subject lines on
occasion. By the time a message has traversed two or three list,
the prefixes take up a good thirty
Hello,
today we released SRM: Script Running Machine version 0.6.0. This release
is the first public beta. The following functions are implemented in this
release:
- Session management
- Remote functions
- Application level variables
- Remote objects
For a full feature list please see:
Hi Alex, *,
the webjames SAPI module, which you maintain, uses a couple of
deprecated macros, namely
CLS_FETCH()
http://lxr.php.net/source/php4/sapi/webjames/webjames.c#178
ELS_FETCH()
http://lxr.php.net/source/php4/sapi/webjames/webjames.c#179
What I don't like is the attitude of the primary maintainer of the
msession extension. He reverts patches by other PHP contributors
without discussing it.
I can't recall ever reverting a patch. I recall being accused of it, and
when I asked for more details about what was lost/reverted
[EMAIL PROTECTED] wrote:
You don't have to like me, personally, I do not think you have been
all the courteous to me, either.
Sorry, I didn't mean to be rude, or uncourteous.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help
Ehh...from manual
n - month without leading zeros; i.e. 1 to 12
So yeah it would print 2th. Cause today is the 10th.
-Chris
-Original Message-
From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]]
Sent: Sunday, February 10, 2002 12:47 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] FWD:
Has anyone applied this patch to their local source tree?
http://bugs.php.net/bug.php?id=9280
It seems to solve the bug and my server is still stable.
(not under much load though, so that could be irrelevant)
Sean
--
===
Sean
On Sun, 10 Feb 2002 [EMAIL PROTECTED] wrote:
What I don't like is the attitude of the primary maintainer of the
msession extension. He reverts patches by other PHP contributors
without discussing it.
I can't recall ever reverting a patch. I recall being accused of it, and
when I asked
Seeing as the mathematically correct way to round numbers is to round down
to n for n-1=m=n.5 and up to n+1 for n.5mn+1, I wonder why the PHP
round() function couldn't include a little 'fuzz' to handle the rounding
problems we encounter due to floating point representation in the hardware?
It
I guess that's because nobody knows beforehand which direction the fuzz should
go - should it go a little upwards or a little downwards in order to match
all systems?
Just my two cents.
Bogdan
Matthew Clark wrote:
Seeing as the mathematically correct way to round numbers is to round down
to
On Sun, 2002-02-10 at 18:15, Andi Gutmans wrote:
At 09:21 AM 2/10/2002 +0100, Sebastian Bergmann wrote:
Markus Fischer wrote:
It is not publicly exposed with ZEND_API(). I can't test
right now, but maybe just need to modify the zend_compile.h
file and prepend the prototype
46 matches
Mail list logo
