On Sun, Sep 09, 2001 at 12:46:17AM +0300, Zeev Suraski wrote:
Fact - gettext(foo) is much less magical and much more understandable
than _(foo).
I think the problem here is that internationalization is
being considered a 'separate module', rather than a core
piece of functionality that PHP
On Sun, Aug 19, 2001 at 07:23:18PM +0200, Hojtsy Gabor wrote:
Text diff is not working at Chora, at least with IE 5.00,
as it thinks that it needs to display XML content, and
just prints out an XML error. Just the Human readable one
works... :((
Please elaborate. Is this not working for
On Sun, Aug 19, 2001 at 12:31:22PM -0700, Rasmus Lerdorf wrote:
Maybe Chora puts out an XML content type header, or
something, that makes IE think this is XML (as it
is not). I can't see the source, as IE just denies
to show the source in such cases saying The XML
source file is
On Sun, Aug 19, 2001 at 11:29:18PM +0300, Stanislav Malyshev wrote:
It does even worse. It tries to guess file type from the content. I hope
somebody will invent some worm that uses this misfeature so that they
would finally fix it...
Guessing the file-type from the first few magic bytes
On Mon, Aug 20, 2001 at 04:01:39AM +0300, [EMAIL PROTECTED] wrote:
well, but if I send foo.gif and it starts with some friendly
VBScript I won't bet you'll think the same.
Yes I would ... I'm referring to content-MIME mapping, and it
doesnt matter if this happens on the client or server, as
Testing PHP-4.0.7RC1 on OpenBSD-2.9, w/ libmcrypt-2.4.15
Mcrypt seems a bit broken; even calling nothing but mcrypt_module_open
results in Warning: Unknown list entry type in request shutdown (0) in ...
Anyone else seeing this problem?
Anil
--
PHP Development Mailing List http://www.php.net/
Cynic wrote:
Of course it is. $foo is conceptually simpler than $_GET[foo].
I don't see how you can say it isn't.
$foo is conceptually a few keystrokes. That's all simplicity
I can see.
I think that's the whole point ...
1) $foo
2) $_GET[foo]
One looks like PHP, the other looks like
Alexander Merz wrote:
Please, could you use relative specifications (font-size: small)
instead of absolute (font-size: 11px) in the css? It's more
user-friendly and i don't have to look for my eyeglasses each time.
Unfortunately, this isn't consistent cross-platform.
Rasmus Lerdorf wrote:
Chuck installed his PHP-based cvs browsing app. It is
available at http://chora.php.net. Go have a look.
I think it looks really good and we should probably make
it the default for http://cvs.php.net. Anybody see any reason
not to do that?
Cool!! A few things I
Rasmus Lerdorf wrote:
By the way, do you think it would be possible to put
the CVS commit message at the top of the long diff
coloured output?
Yeah, I've already got a similar change in my local tree that shows the
commit message on the checkout. I'll add it in for the diff view as
well.
[EMAIL PROTECTED] wrote:
Ok. I need to sit down and document how to add a
C extension to PEAR.
Has anyone worked on enabling multiple SAPI modules in one compile yet?
Stig committed some stuff a while back but reverted it.
If that's done, and we can generate a CGI version of PHP at the same
Stig made a brave attempt at allowing the compilation of multiple SAPI
modules simulataneously a while back, but I think this never made it
through to php-4.0.[5|6].
Is there any chance this could get looked at before 4.0.7? It would
make it so easy to install the CGI binary for PEAR as well as
Andi Gutmans wrote:
Please test it http://www.php.net/~andi/php-4.0.6RC4.tar.gz
No problems so far on OpenBSD-2.9-stable/i386
4.0.5 gave me annoying problems of an httpd process going into an
endless loop taking up 100% cpu. This doesn't appear to happen any more
with 4.0.6, although it's a
[EMAIL PROTECTED] wrote:
$version_id = xml_version();
or
$version_id = ibase_version();
Probably better to do something like this:
$version = get_extension_version('xml');
to avoid cluttering the namespace with more functions.
Although, why not just use phpversion() ? Extensions aren't
Without more information it's pretty impossible to solve (I don't have
access to an iPlanet installation at the moment). Can anyone else look
at the problem with iPlanet 4.x?
Otherwise you'll have to try to dive in yourself, Mark. Did it work
with an older version of PHP? Try looking at the
Zeev Suraski wrote:
Deciding 4.0.6 won't include any significant new features,
and that we'll start its release process after a bugs-database
-cleaning period sounds like a good idea to me.
So why restrict it to just the next release? It might make a lot of
sense to have an RC candidate
ALL extensions are in PEAR, and a download tool allows easy
selection of extensions, perhaps with a 'most common options'
button to include the favourite extensions.
Also, if you put most of the extensions into PEAR initially, it would be
easy to monitor the download statistics to find the
Derick Rethans wrote:
I would go for optionally on, I really dont want to build both
the apache module (p.e.) AND the CGi at the same time.
For QA testing this is fine, but not for production servers.
Well, it really beats the alternative, which is to compile everything
twice ... what's
Sascha Schumann wrote:
No. The alternative is to pass --enable-cgi on the command-line.
?
This doesn't work (nor is it listed in the --help options to configure)
I mean to compile a CGI and APXS DSO in a single compile, not two. My
understanding is that only one SAPI module can be selected
It's the arg_separator changes isn't it? Both '' and ';' are valid
delimiters in a URL, so the new 4.0.5 behaviour is actually the valid one, I
believe. Refer to the XHTML specification, or check out the bugs db for
this.
Anil
- Original Message -
From: "Andi Gutmans" [EMAIL
Andi Gutmans wrote:
Does anyone else have any critical bug fixes
which need to be in 4.0.5? (I mean critical ones and not
huge patches).
Zeev's output buffering fix hasn't been committed yet; it's a one-line
change, and it makes the transparent output compression stuff work.
Does anyone
Andi Gutmans wrote:
I suggest you merge this into 4.0.5 because it seems to me
that otherwise output buffering will be quite a mess without
it. It would be a shame to release 4.0.5 without it.
Ok, done.
Your fix looks OK but I'd like to hear the opinion of someone
else who is more familiar
Making HEAD requests to a page which has had output buffering activated just
results in the connection being closed with no response. This makes it
pretty unusable. Can anyone else reproduce this problem?
Two scripts:
nobuffer.php:
? print "hello world!"; ?
buffer.php:
? ob_start(); print
I'll upgrade to RC4 in a bit and check if that makes a difference (not
seen
the ChangeLogs between them yet)
(Platform is OpenBSD-2.8-stable). There is nothing in the Apache error
log.
The problem is still there in RC4 also.
Anil
--
PHP Development Mailing List http://www.php.net/
To
One of my OpenBSD servers hosed itself overnight, after the upgrade
to PHP-4.0.5RC1. The problem was that the webserver suddenly
segfaulted all of its children (saw this in the error log), and then dumped
around 900MB worth of errors into the error log. This hurt my /var
partition :-)
The
Zeev Suraski wrote:
Stability is irrelevant with new modules - they did not exist before, so
they can't be less stable, and figuring whether their addition breaks PHP
is trivial, and would be discovered in a second if they manage to do that
somehow. New modules are no different from any of
This has come up a few times, but is there any chance of having a
bi-directional popen() that doesn't depend on the underlying system
call supporting it?
It would hugely speed up and clean up a lot of code that interacts
with the system, but right now it only works under FreeBSD/BSDi
that I
Sean R. Bright wrote:
Because I don't consider it a problem that needs solving. I am probably
overlooking some notoriously famous algorithm, but I can't think of a
valid
reason for such functionality to exist unless someone is purposely trying
to
bring a system to its knees.
How about ...
, if they did use brackets wrongly, so an entry in
NEWS ought to enough ?
--
Anil Madhavapeddy, [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail
for production yet. I'm
working on the MIME stuff at the moment, and the UI is still a bit
shaky. Feedback, as always, is more than appreciated (especially about
new ideas for the interface). Patches are even more appreciated :-)
--
Anil Madhavapeddy, [EMAIL PROTECTED]
--
PHP Development Mailing
, then it would be a lot
more worrying, but how many people use the _readline_ module with PHP?
I'm sure all two of them would find an alternative if it were to
disappear :-)
--
Anil Madhavapeddy, [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED
to the functions not being there
(yafc), but christos says that he is gunning for full readline compat,
which should be excellent.
--
Anil Madhavapeddy, [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
from running
$ dnstrace a www.php.net 198.41.0.4 | dnstracesort
--
Anil Madhavapeddy, [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail
? With the rise of PEAR,
it's more and more important to provide a binary, and I'd like
to install it by default on the OpenBSD port. However, it seems
a bit wasteful to require two compilations, when the vast majority
of what is compiling stays the same.
--
Anil Madhavapeddy, [EMAIL PROTECTED]
--
PHP
34 matches
Mail list logo
