On 08 May 07:26, Sebastian Bergmann wrote:
> > When will be the first official release of PHP 5.0.0?
>
> We are currently working towards a release in (mid-)July with a last
> Release Candidate 2 to 4 weeks before the final release.
"Dein Wort in Gottes Ohr ..."
regards dtg
--
PHP Interna
Andrew M. Johnstone wrote:
> When will be the first official release of PHP 5.0.0?
We are currently working towards a release in (mid-)July with a last
Release Candidate 2 to 4 weeks before the final release.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpe
Long ago I was told constants could only be scalars, so I accepted it.
Certainly ZEND_FUNCTION(define) does the check to ensure it's a scalar, but
why?
For what I can tell a zend_constant is just a container for an ordinary zval
which is refcounted and all that fun stuff. I don't see any obvious
On 08 May 03:30, Andrew M. Johnstone wrote:
> I realize this is probably a big question; however, it will determine the
> outcome of a project I am working on. When will be the first official
> release of PHP 5.0.0?
It's finished, when it's finshed. Do not expect a satisfying answer, as I
did for
I realize this is probably a big question; however, it will determine the
outcome of a project I am working on. When will be the first official
release of PHP 5.0.0?
[29-Jun-2003] PHP 5.0.0 Beta 1
[30-Oct-2003] PHP 5.0.0 Beta 2
[18-Mar-2004] PHP 5.0.0 Release Candidate 1
[25-Apr-2004] PHP 5.0
You want to implement a wrapper for PHP streams:
http://www.php-mag.net/itr/online_artikel/psecom,id,368,nodeid,114.html
--Wez.
> -Original Message-
> From: Srdjan Mijanovic [mailto:[EMAIL PROTECTED]
> Sent: 07 May 2004 18:52
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Read PHP script
> > > This topic got quietly dropped last week, but I'd like to make one
last
> > > plea. I'd like to see Zend throw an E_STRICT when arrays are
implicitly
> > > created. I know there were objections to E_NOTICE, but did anyone
have
> > > violent objections to E_STRICT?
> > >
> >i like to see one
Well, if you can get the file source out of the archive into a string, you
could then eval() it.
Hope this helps,
Jevon
- Original Message -
From: "Srdjan Mijanovic" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, May 08, 2004 5:51 AM
Subject: [PHP-DEV] Read PHP script from.
Won't you then have to recursively initialise multiple dimension arrays?
$a = array();
$a[0] = array();
Otherwise, isn't this implicitly creating arrays? (I didn't quite understand
the last time)
Jevon
- Original Message -
From: "Jason Garber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]
I would view implicit array creation as a slightly negative thing, similar
to accessing the value of a variable that does not exist.
We run in E_ALL mode and write our code to avoid all E_NOTICEs. For
instance, before using an array, I always initialize it using $aItems =
array();
I'm in favo
On Fri, 2004-05-07 at 18:26, Christian Schneider wrote:
> I guess the question is whether we want to deprecate the automatic array
> creation at some point as E_STRICT is meant for that case. Otherwise we
> are abusing E_STRICT and might render it unusable to some degree.
I was also under the im
Hello Sara,
i like to see one of those too and i have no preference for one of them.
marcus
Friday, May 7, 2004, 11:05:15 PM, you wrote:
> This topic got quietly dropped last week, but I'd like to make one last
> plea. I'd like to see Zend throw an E_STRICT when arrays are implicitly
> created
Sara Golemon wrote:
plea. I'd like to see Zend throw an E_STRICT when arrays are implicitly
created. I know there were objections to E_NOTICE, but did anyone have
violent objections to E_STRICT?
I guess the question is whether we want to deprecate the automatic array
creation at some point as E_
This topic got quietly dropped last week, but I'd like to make one last
plea. I'd like to see Zend throw an E_STRICT when arrays are implicitly
created. I know there were objections to E_NOTICE, but did anyone have
violent objections to E_STRICT?
-Sara
--
PHP Internals - PHP Runtime Developmen
> Oki, second attempt. Perhaps att better solution:
>
> #define _XOPEN_SOURCE
> #define _BSD_SOURCE
>
> #define __EXTENSIONS__
> #include
>
> #include "php.h"
> #include
> #include
> [...]
>
> compiles on both Solaris and Linux. (at least when I try it
> at home) :)
> I have only tried it o
On Fri, May 07, 2004 at 08:12:54PM +0100, Wez Furlong wrote:
> Any help would be appreciated; essentially you need to find a way to get
> ulong defined with the _XOPEN_SOURCE and _BSD_SOURCE symbols defined.
>
> You might find that you need to specify a numeric value (the year or
> revision number
Wez Furlong wrote:
>
> Hey Jay,
>
> That would be great; I tried to reach the box when I discovered the bug,
> but it wasn't there :-)
>
> If the login and port are still the same, I'll try it over the weekend.
>
> Thanks,
>
> --Wez.
>
Everything should be as it was before. That box went d
I have Solaris 9 X86 in a VMWARE and a Solaris 9 Sparc Server... Could help
with this.
At 21:48 07.05.2004, Wez Furlong wrote:
Hey Jay,
That would be great; I tried to reach the box when I discovered the bug,
but it wasn't there :-)
If the login and port are still the same, I'll try it over the
Hey Jay,
That would be great; I tried to reach the box when I discovered the bug,
but it wasn't there :-)
If the login and port are still the same, I'll try it over the weekend.
Thanks,
--Wez.
> Hey Wez,
>
> Conincidentally enough, just yesterday I ressurrected my
> Solaris box, so if
> yo
Wez Furlong wrote:
> This is a known issue (search bugs.php.net).
>
> Unfortunately, the workaround you (and the others) suggest will cause a
> similar problem on Linux systems :-/
>
> We need to find a way to set those _XOPEN_SOURCE style defines up so that
> the build succeeds on your system.
> Well. A simple solution that should keep the build on Linux
> (and others)
> intact is
>
> #ifdef __sun__
> #include
> #endif
>
> Perhaps not the neatest one, but then it should compile on
> Solaris using
> gcc.. Better then not compile at all :)
Better to do it the right way, which is why I
On Fri, May 07, 2004 at 02:00:31PM +0100, Wez Furlong wrote:
> This is a known issue (search bugs.php.net).
>
> Unfortunately, the workaround you (and the others) suggest will cause a
> similar problem on Linux systems :-/
>
> We need to find a way to set those _XOPEN_SOURCE style defines up so t
Hello,
I'm quite new to this newsgroup, and I hope this is the right place to ask
the question.
I want to be able to read PHP source files from an archive. Script is not
present on the hard disk, but inside a file / archive. To do this, I can
supply the zend_stream object for reading and writing.
On Fri, 7 May 2004, BUSTARRET, Jean-Francois wrote:
> Let's get rid of this useless (when using a cache) realpath call, without having to
> migrate to PHP5 !
Well, the realpath call's usefulness doesn't have anything to do with the
cache. It is there to provide a canonicalized absolute pathname
This is a known issue (search bugs.php.net).
Unfortunately, the workaround you (and the others) suggest will cause a
similar problem on Linux systems :-/
We need to find a way to set those _XOPEN_SOURCE style defines up so that
the build succeeds on your system. However, I don't have access to a
Hello
I'm having compile issues with PHP5 on Solaris. I tried both Solaris 8
and 9, both giving me the same error. The problem is in the file
ext/standard/proc_open.c
And the error message from gcc is:
In file included from
/Home/staff/fahlgren/php-test/php5-200405071030/Zend/zend.h:244, from
/H
I wrote a test script for this and compared the output of the test script
with the output from the earlier posted class method.
Really strange is that the test script will have the same result as the
32bit machines (the correct one).
Maybe an memory managment problem within classes? Or any other i
Maintaining/translating the documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
On Fri, 7 May 2004, Mehdi Achour wrote:
Should I change the documentation to say that ".*" can be a constant name, but
that we recommand [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* ?
Just leave it as is.
I wanted to complete the TODO commented on languages/constants.
On Fri, 7 May 2004, Mehdi Achour wrote:
> Should I change the documentation to say that ".*" can be a constant name, but
> that we recommand [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* ?
Just leave it as is.
Derick
> Mehdi Achour wrote:
> > Hi !
> >
> > The manual reads :
> >
> > "The name of a co
Should I change the documentation to say that ".*" can be a constant name, but
that we recommand [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]* ?
Mehdi Achour
Mehdi Achour wrote:
Hi !
The manual reads :
"The name of a constant follows the same rules as any label in PHP. A
valid constant name starts
I know the location is not the best one (IMHO, the PEAR default is not much metter).
You can't always have the fastest setup, because there are many other factors to
consider (security, ease of management, number of servers/apps to handle, ...).
My point was to evaluate the impact of the patch
32 matches
Mail list logo
