On Wed, 18 Dec 2002, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Sebastian Nohn wrote:
I think a lot more users will be pissed of when renaming php to php-cgi than
regarding to the cli-version of php as php-cli or phpsh or anything else.
The best solution would be indeed bundling both to
On 18 Dec 2002, Xavier Spriet wrote:
Well it's up to whoever has karma to make that decision.
People can give their opinion obviously but shouldn't expect to actually
make the decision.
That's the problem with the current state of PHP development.
Too many people think that their
On Tue, 17 Dec 2002, John Coggeshall wrote:
Can someone enlighten me as to why session_register() and $_SESSION
shouldn't be used togeather? It seems to me the session_register()
function(s) should just be working with $_SESSION anyway... Are they
doing something different? Is this desired
Isn't that an error that 4.2.3 throws when session_register() is used as
well as
registering directly in $_SESSION?
So the message is not easily comprehensible, I suppose.
There is no problem when you have register_globals enabled
and you mix session_register and use of
On Thu, 12 Dec 2002, Andrei Zmievski wrote:
With the new build system, is there a way to clean/build just one
extension, as opposed to having to do it to the whole tree? Something
like make clean ext=wddx, perhaps?
We could add a target clean-ext-EXTNAME..
- Sascha
--
PHP
On Thu, 12 Dec 2002, Andrei Zmievski wrote:
On Thu, 12 Dec 2002, Sascha Schumann wrote:
We could add a target clean-ext-EXTNAME..
- Sascha
What about build-ext-EXTNAME? I ran into this yesterday when I checked
out a fresh copy of the tree and wanted to build only wddx module
added with PHP_ADD_LIBRARY and without further checks. Also some libraries
are linked more than once.
That's not a problem.
Should we change PHP_ADD_LIBRARY and PHP_ADD_LIBRARY_WITH_PATH
to check whether the library was already added and whether at least the
file exists?
No. It's
On Wed, 4 Dec 2002, Preston L. Bannister wrote:
That would be a big YES - as in practically all C++ compilers. It was a
part of the draft ANSI standard for C++ for rather a long time (but not in
the final standard?).
Page 309, 16.8 Predefined macro names, of ISO/IEC 14882:1998
lists
I bet m4 --version shows GNU m4 1.4o or similar.
Using GNU m4 1.4 as located on ftp.gnu.org/pub/gnu/m4/ fixes
these issues.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 2 Dec 2002, Andi Gutmans wrote:
I still haven't understood from your answer if this is a problem which was
in 4.2.x.
This problem has existed for a long time. There is not
much which can break, because it has not been working since
well before 4.2.x.
- Sascha
--
PHP
-1 on errno-style error codes. They are not versatile
enough or easy to manage.
They are a lot more versatile and manageable than having to use
substring/regexp matching on human-readable text.
What I'm going for here is a way for scripts to detect _why_ fopen fails,
other than
On Sat, 30 Nov 2002, George Schlossnagle wrote:
A little off-list discussion has sold me on the linked list
implementation. Seems very fast and very simple.
O(1) operations are hard to beat. Note that free lists are
not primarily about speed, they are also an extremely helpful
Hi!
For all of you who are interested in running IRCG in
combination with Apache 1.3, have a look at:
URL:http://schumann.cx/ircg/ircg4.php
--
About IRCG
IRCG is a revolutionary way for dispatching messages to huge
groups of users over an arbitrary
On Fri, 29 Nov 2002, J Smith wrote:
Attached is a patch to ext_skel that adds an optional argument (--cpp) that
will create a PHP extension in C++ rather than C. Also attached is
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
modifications for using C++. I could've
On Thu, 28 Nov 2002, Edin Kadribasic wrote:
Forget the patch, its not working well. The problem is that with
session autostart SID constant gets defined in rinit and gets
destroyed twice.
Yes, that's why I don't like to rely on internals of
something which should be a black box. The
The attached patch fixes a crash in CLI when php.ini contains:
session.auto_start=1
magic_quotes_gpc=1
Could you please review it?
SID is neither persistent nor case-sensitive. We should
resort to such a hack only, if there is no proper bug fix.
- Sascha
--
PHP Development
On Thu, 28 Nov 2002, J Smith wrote:
A couple of times a month, I get questions about from people looking to use
C++ with PHP. Apparently, a lot of people end up reading some post I made
to php.dev or something a year or so ago about C++, and although it worked
at the time, the procedure I
AFAIK, PHP is designed to function on any standard ANSI-compatible C
compiler (as a goal). Unless this has changed, I don't know if opening
the door for C++ development is the best of ideas (IMHO)
That just means that the core and standard extensions need to
be written in ISO C and
On Tue, 26 Nov 2002, Derick Rethans wrote:
On Mon, 25 Nov 2002, George Schlossnagle wrote:
By the way, could you please advise by how much I will need to
increase the
power of my server(s) to maintain the same level of performance?
Why would this need to kill your performance if
Since error code domains need to be centrally assigned so
that they don't overlap, I'd suggest to simply set up a
central data repository with assigned error code domains and
a per-domain set of mappings.
The error codes should be easily recognizable (%foo-123%), so
that
Billy tried localizing programming languages as well. Remember Excel
95? It ended up in complete disaster and was removed in the next
office version.
The language won't chance. Stop the FUD.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
On Tue, 26 Nov 2002, Maxim Maletsky wrote:
I apologize for shouting, didn't mean to be offensive. What I want to
say is that error messages are string and should, IMHO, be reference
instead of hardcoded in the C code.
The default messages must stay; there is no need to _always_
A possible implementation would look like this:
A new ini setting is added.
php.error_lang
A new function is provided.
php_error_ex(int type, const char *err_code, const char *fmt, ...);
The function tries to lookup the err_code key in
This is not FUD. He brought up the issue of M$ practises. And I didn't
hear you answer the question about why is parse error more difficult to
understand than register_shutdown_function?
You need to learn a bit about writing good compilers. It is
easy to write a compiler; it is hard
Can you guys please quit bickering and focus on the concrete
proposal which is on the table.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
ext/session/errors/en.cat
Sounds good.
Also, a logic to always use english error as default.
Note that the English format messages stay in the source
code.
This does not cover message catalogues for extensions yet --
similar to the ini-directory, the php_error_ex function
This does not cover message catalogues for extensions yet --
similar to the ini-directory, the php_error_ex function could
try a number of message catalogues in a defined msg-catalogue
directory, before falling back to the English format message.
(I'm referring to
On Tue, 26 Nov 2002, Derick Rethans wrote:
On Tue, 26 Nov 2002, Sascha Schumann wrote:
ext/session/errors/en.cat
Sounds good.
No, it does not to me. It means that translators need to have access to
the php4/ cvs module, which is something I'm very against.
Agreed
I think starting with a concrete proposal before it's not clear if we
even want this localized errors thing seems rather time-wasting. What
you call bickering, I call discussing, and IMO we're not yet done
discussing if we want this at all.
Well, there won't be a consensus regarding i18n
On Wed, 27 Nov 2002, Stig S. Bakken wrote:
On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote:
On Tue, 26 Nov 2002, Edin Kadribasic wrote:
On Tue, 26 Nov 2002, Maxim Maletsky wrote:
I rather propose. And, it seems to interest many on the list.
Don't forget that there seem to be
On Mon, 25 Nov 2002, Tim wrote:
OK, so I'm wrapping a C++ library as a PHP extension, and I want one of
my functions to return an object that has arrays as fields of it. I
have created the arrays:
Is that object supposed to have functions associated with it?
If not, why not return
If this thread was about error messages of a C compiler, I
would agree that users can be expected to understand English.
That is a completely different level you are dealing with then.
However, PHP needs to take beginners into account.
Simply assuming that everyone must
Whereas assuming that PHP users are too stupid to understand english is
not at all arrogant? :)
Wrong, Sterling. Beginning PHP users might neither have
formal education in computer science _nor_ foreign languages.
The reason here is not about intellect; it is about requiring
On Mon, 25 Nov 2002, Daniel Lorch wrote:
hi,
What you're missing is that currently to program PHP, you need a reasonable
understanding of english. [..]
I agree with Sterlin. I mean, what's next? Also localize language constructs?
Daniel, Sterling is arguing in favor of having
Looks like some program in the chain erroneously appended
@vckyb3.nw.wakwak.com.
- Sascha
-- Forwarded message --
Date: Mon, 25 Nov 2002 23:31:08 +0100 (CET)
From: Sascha Schumann [EMAIL PROTECTED]
To: Moriyoshi Koizumi [EMAIL PROTECTED]
Cc: Alexander Wagner [EMAIL
This happens to tons of php developers across the world, its not really that
hard, and it really does open up pandora's box, also from an implementation
perspective, its alot more feasible for Oracle than for PHP...
Sterling, please take a step back and look at this issue
through the
On Mon, 25 Nov 2002, Ilia A. wrote:
On November 25, 2002 08:29 pm, Maxim Maletsky wrote:
Who cares? I am an Oracle fun, but this is still not my point. My point
is that oracle, as arguable as can be, thinks about marketing its
product. They biggest sales point, in fact, is not the
On Mon, 25 Nov 2002, Shane Caraveo wrote:
I am completely +1 to the concept of taking error codes out of the PHP
core and replacing them with an XML document, period.
I had wanted to avoid this whole thread, but decided to read this one
message, and ouch. While I'm all for
cats or gettext comes to mind.
Neither are usable, though, because PHP would need to support
multiple concurrent message catalogues on a per-thread base.
gettext/catgets associate exactly one language with each
process through the use of environment variables, so that
they
Why? The error messages are for the developer, not the masses. But
Imagine someone using his web-hoster's environment for
debugging purposes. This affects the masses.
generaly I agree with using something else. More the point is that
stuff exists, techniques exist, no need to
On Sun, 24 Nov 2002, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2002-11-12 13:08:33 +0100:
On Tue, 2002-11-12 at 07:54, Derick Rethans wrote:
And that's why I would be -1 on the first one. However, the whole
error reporting is a pretty mess, with some extensions implementing
other
The same script doesn't work for me with Engine 2 bison 1.28 and Engine 1
bison == 1.75 (I haven't tried other combinations yet.
So this doesn't seem to be only an Engine 2 problem.
Ok, then a suppressable configure-time check needs to be added.
- Sascha
--
PHP Development Mailing
Since PHP distributions are shipped with bison and flex files pre-built, isn't
it more logical to put the chek in ./buildconf?
Again:
buildconf does not run bison.
There is no point to put a bison check into buildconf.
The bison version number should be checked before bison
Again: bison is not run at all when compiling a regular PHP version. The files
generated by bison and flex are bundled in the source tarball.
In order to accomodate regular administrators, the already
existing bison check in configure should be extended to
display appropiate
Seems like php-config misses something.. :)
php4/pear/scripts/php-config.in should propably be using
PHP_LIBS and PHP_LDFLAGS. Now it uses EXTRA_LIBS only..
And for some reason PHP_LIBS is empty.
Sounds like a pure synchronization issue to me.
- Sascha
--
PHP
Could someone explain to me why install-headers, programs,
build are treated as if they cannot be separately installed
from the pear scripts?
if test $PHP_PEAR != no test $disable_cli != 1; then
install_pear=install-pear install-build install-headers install-programs
On Sun, 13 Oct 2002, Zeev Suraski wrote:
Sascha,
What I, at least, fail to understand is the answer to Rasmus' initial
question(s):
- Are we going to break compatibility? If not, then why are we spitting
out this error by default?
If you have followed the exchange, you will have
I have followed it, even though I don't recall ever seeing a clear-cut
statement to that extent.
It is very likely that you are missing the central issue here
as well. Please see the example as posted by Rasmus
http://news.php.net/article.php?group=php.devarticle=89364
and
On Fri, 11 Oct 2002, Rasmus Lerdorf wrote:
Sascha, would you mind explaining the reasoning for changing this
behaviour? Whether it is documented or not, I'd like to hear a technical
reason for not allowing session_register() to act on global variables when
register_globals is off. I still
Rasmus, if you were arguing for adding a second class of session
variables which are always available through and looked up in
the global symbol table, you actually had a point. I
completely disagree though with your interpretation of the
outdated, unmaintained
With PHP 4.3, it finally becomes possible to completely
manage session variables without any dedicated functions.
Just set or unset variables in $_SESSION and you are done
with it. It could not be any easier.
The streamlining of the serialization process also has
another
On Wed, 9 Oct 2002, Wez Furlong wrote:
I thought that I'd try this out with HEAD, but I found that PHP would
go into an infinite loop. I didn't have time to debug it, so I reverted
to using a regular path instead. Could a session guru take a look and
double check this?
I'd like to do a collective rethink of this. The simple description of
the session_register() function in the manual is:
This description was correct initially (I wrote it), but has
not been updated as the session module was extended. I've
noticed this documentation issue in the
On Tue, 8 Oct 2002, Melvyn Sopacua wrote:
Wez,
there's something going wrong with the autoconf logic config.m4 section I
sent a while back.
I'll look into it.
As with SysV shared memory, the extension should define its
own structure, if struct msgbuf is not found on the system.
The struct msgbuf as defined, for example here:
http://ou800doc.caldera.com/cgi-bin/man/man?msgop+2
defines mtext member as mtext[] while FreeBSD defines it as mtext[1].
Yes, mtext[] is not a valid ISO C construct.
The structures of the SysV IPC interfaces are generally not
It's not a typedef but the struct itself that's provided, so that doesn't work.
I'm curious. The following code works here.
struct foo { int a; };
typedef struct foo php_sysmsg;
What did not work for you?
Just using struct php_sysmsg is fine, too.
It boils down to:
Good point - but also raises, whether to look for this struct in the first
place.
Why not skip it all, and define it ISO C compliant, in php_ namespace?
That would be a possibility, although you never know how
engineers at some random company interpreted the standard text
(if they
Anyway, using unlimited size of buffer makes sense to me.
Unless it buffers whole contents, URL rewriter may fail to
modify HTML correctly.
I don't read code, so I cannot make comment on this.
Right, you did not read the URL rewriter code and so you
should not comment on it.
A couple of questions for clarity:
(a) Does this work properly with PHP 4.2?
There is an even weirder bug, at least in the 4.2.3/CGI case
(the session output handler gets called after the request
shutdown which already disabled the session, so that the
rewriter is not
On Mon, 7 Oct 2002, Zeev Suraski wrote:
Can you see if calling php_end_ob_buffers() in the session deactivate
function, in case BG(url_adapt_state_ex).active is true, solves this problems?
Note the condition here:
There is an even weirder bug, at least in the 4.2.3/CGI case
I understand, but what if you don't call ob_flush()? Does it work properly?
The bug from 4.2.3 does not reappear here. The rewriter
kicks in using the final combination of ini settings.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
This is causing me problems in an environment where /usr/lib is not the
default primary link directory and I need to explicitly add it to get
stuff to compile right. Why is this check here? Just to pretty up the
link line? Would it hurt to leave this check off so /usr/lib can be
forced on
Hi,
the recent changes in the output buf layer are causing PHP to
buffer data too aggressively.
The test case outputs two lines of HTML a few times and
expects these lines to be immediately forwarded to the url
scanner. Regardless of the output_buffering/implicit_flush
The stream system assumes that the callee always wants to
consume *exactly* as much data as the callee is specifying.
This is not the case with sockets where read/recv specify the
*maximum* amount of data to read.
I've verified that PHP 4.3 behaves like earlier versions with
Here is a second patch, with a third coming some time later.
The current stream implementation does not consume its
buffered data before starting new reads. That causes serious
problems with sockets, of course, if you have an application
which exchanges commands/replies with
Are we going to have the streams stuff sorted before tomorrow?
Are there any problems with regard to comitting fixes to that
branch?
Anyway, I've had to address such issues in PHP 3 already for
which I wrote the socket buffering system. I don't expect to
run into anything
On Fri, 4 Oct 2002, Rasmus Lerdorf wrote:
Guys,
Are we going to have the streams stuff sorted before tomorrow?
I don't think there is anything too magical about Saturday. The magic was
setting a date which has spurred a lot of good fixes. If we need to give
folks a couple more days
B. reading a byte at a time (that's how it was done previously).
Well, actually, that is not the case. Since PHP
3.0.something, PHP used a socket buffering system for
reading data from the network. Since then, no single byte
reads were necessary.
Watch PHP 4.2 fgets'ing
Iliaa,
looking at a syscall trace from PHP 4.2, the difference in
handling php://std* is that 4.2 uses non-blocking mode by
default, while streams block by default.
4.2: fcntl64(0x3, 0x3, 0x8050fe5, 0) = 2
4.3: fcntl64(0x3, 0x3, 0xb7f4, 0x3) = 2
Ilia,
unfortunately, I cannot view your patch -- it was not
Cc'ed to me and news.php.net does not know about text/x-diff
yet (Jim, could you please add that?).
Wez,
it looks like the default blocking behaviour of fill_read_buffer
is causing several bugs :-)
Streams' gets function does not work with stdio, because it
uses fread(3) instead of fgets(3). Like fill_read_buffer
earlier, fread(3) does not return, unless an error occurs or
the amount of data has been read completely. It is basically
impossible to implement an
- Disable buffering for stdio streams (setvbuf(3) or similar).
- read(2) using the fd obtained from fileno(3) (where valid).
Ok, here is a plan:
1. Use fgetc in stream_gets for stdio stream ops
2. Add file descriptor-based stream ops
3. Redirect
The session test scripts need to set register_globals -- does
anyone see a problem with making that option setable in the
script?
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
No, but I wonder how you would like to implement this. Globals are
put into the corresponding arrays before the script runs...
The session module reads register_globals as well.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
On Thu, 3 Oct 2002, Derick Rethans wrote:
On Thu, 3 Oct 2002, Sascha Schumann wrote:
No, but I wonder how you would like to implement this. Globals are
put into the corresponding arrays before the script runs...
The session module reads register_globals as well.
Makes sense
Could some kind soul with a thorough understanding of the
engine details please review the attached patch?
Changes:
- Fix two simple memory leaks.
- Fix a bug which did not initialize $_SESSION, if
is_array($HTTP_SESSION_VARS) was true.
- Sascha
Index: session.c
you mean 4.4? our new rules says to merge only fixes into
a release branch.
Will HEAD become 4.4 immediately after 4.3.0 branches off?
I would expect that some work needs to be done to further
stabilize the 4.3 branch.
- Sascha
--
PHP Development Mailing List
believe should be addressed. The problem being that session_register()
function does not work unless the user has register_globals enabled.
I think there is a misunderstanding with regard to how
sessions interact with global variables.
The session extension makes use of globals
Its very simply really, as you well know, since PHP 4.2.0 register_globals are
off by default. Because they are off, session_register does not retrieve a
value from the variable and only creates a null variable inside the session.
So, unless the user is aware of this issue and knows that to
On Wed, 2 Oct 2002, Rasmus Lerdorf wrote:
I really don't see why would want to deprecate session_register().
Regardless of whether register_globals is on or off, code like this works
fine:
Set a session var:
session_register('a');
$a=1;
Get a session var:
session_start();
$a =
But that is a bit of a twist of what register_globals is supposed to
mean. As far as I am concerned register_globals only affects how data is
imported into PHP. Having that flag trigger other behaviours is
completely undocumented and outside the scope of the original intent of
On Wed, 2 Oct 2002, Rasmus Lerdorf wrote:
That example only works when register_globals are on. When they are off, it
Up until 4.3 it worked just fine.
Yes, there were a series of modification with regard to
$_SESSION which -- modified some of the behaviour.
get_session_var
On Wed, 2 Oct 2002, Rasmus Lerdorf wrote:
Hrm, but that documentation is very out of date and didn't match the code
even when it was written.
Huh, excuse me, would you please leave that judgement to the
authors of the code and the documentation (Andrei and me).
The documentation
I am assuming this documentation was not written recently since it talks
about track_vars and there is no way to turn off track_vars today. And
You are right -- it was not written recently. The semantics
of the session module have not changed since then though. If
a bug
Are you sure it was only 4.2? I seem to remember seeing similar code in
4.1.
Possibly. We changed the serialization strategy which is
appealing because of its simplicity, but it is not backwards
compatible.
I'll commit my changes so far (the patch I posted earlier),
tag
On Tue, 1 Oct 2002, Andrei Zmievski wrote:
Sascha,
Edin tells me that with the changes you made it will be necessary to do
the configure-make cycle 3 times in order to build PHP + libphp.so +
libphp.a. In my view, that is a big hassle. Is there no way to make it
work so that everything is
Well, again, I invite you to work on this issue in a
constructive way.
For example, your input regarding php-gtk would be valuable
-- is there anything in my notes which would affect a complex
extension such as yours?
- Sascha
--
PHP Development Mailing List
I appreciate your effort on making SAPI part of the build more flexible, but I
really think that it is unlikely that such a level of flexibility is needed.
I might be wrong, but I think that a typical user would very seldom require
more than 1 SAPI + CLI + LIB to be built.
I would argue
On Tue, 1 Oct 2002, Andrei Zmievski wrote:
On Tue, 01 Oct 2002, Sascha Schumann wrote:
Fortunately, I have some spare time and look forward to
purge some of the cruft which has assembled since the CLI
support was added. By extending the problem domain, we can
simplify
On Tue, 1 Oct 2002, Andrei Zmievski wrote:
On Tue, 01 Oct 2002, Sascha Schumann wrote:
Nope, this is 4.3.1 material.
I was about to ask you whether you can branch away the PHP
part now and doing the Zend branch later, after the bug is
fixed. If not, it is ok, too
how should it be possible
to get the rewriter NOT to add the hidden input but
only add the session id to the action url?
That is only manually possible - at least, I'm not aware of
any situation where this would be preferable (enlighten me).
If a user for whatever
FYI, autoconf 2.5x contains a cache system which aims at
giving back some of the speed the heavy macro usage took
away. The cache system does not properly maintain
dependencies (e.g. it apparently does not track sinclude()
usage) and thus autoconf 2.5x will sometimes use
On Sun, 29 Sep 2002, Edin Kadribasic wrote:
Hi Sascha,
Without going into the specifics of my implementation of embeddable phplib at
this point, don't you think the author of the implementation should be at
least asked for his motivation for doing things in a particular way before
you just
But sometimes they add desired functionality. Like building CLI at the same
time as another SAPI module. This hack has worked quite well for the past
half a year or so and it is generaly considered very stable. At least I have
not heard that there were problems with it.
The CLI build is
If you are discussing something with me, don't remove my
address from the Cc line, or I won't see your email. I'm not
subscribed to any PHP mailing list at this time and only
occasionally browse news.php.net.
- Sascha
--
PHP Development Mailing List http://www.php.net/
To
Ok, my notes include now:
- PHP_SELECT_SAPI will be extended to also cover ZTS
PHP_SELECT_SAPI(name, type[, sources [, extra-cflags [, zts]]])
zts is either
empty -- works with non-ZTS only (common case)
or 1 - ZTS only
or 2 - works with both (e.g. CGI, embed)
On Sun, 29 Sep 2002, Jon Parise wrote:
On Mon, Sep 30, 2002 at 02:38:18AM +0200, Sascha Schumann wrote:
- The meaning of PHP_NEW_EXTENSION's sapi_class parameter
will be extended to allow a *list* of SAPI module names
with which the extension can be compiled
On Wed, 25 Sep 2002, Edin Kadribasic wrote:
For some reason http status reporting has been changed in the current CVS
version of PHP. This breaks PHP under IIS and possibly other servers. Please
see http://bugs.php.net/bug.php?id=19207 for details.
The reason is that it did not work
This is probably the best solution to the problem. We just have to
remember to explain the issue in the release notes when 4.3.0 gets
released. Perhaps also make the old format default on Windows since
probably most people use php-cgi with IIS.
Well, I am not so certain about that --
And browser has cookies disabled. The hidden entry does not appear.
Sometimes it does appear..but I haven't figured out why yet.
Using latest CVS HEAD..
Did it work in newly started Apache children and failed in
reused ones? That would be a pattern at last.
The
101 - 200 of 474 matches
Mail list logo
