[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/mysql php_mysql.c
Georg Richter wrote: georg Sun Jan 5 15:53:06 2003 EDT Modified files: /php4/ext/mysql php_mysql.c Log: fixed bug #21435 php_mysql.c(1004): warning C4047: 'function': Anzahl der Dereferenzierungen bei 'struct _zval_struct ** ' und 'struct _zval_struct *' unterschiedlich php_mysql.c(1004): warning C4024: 'zend_fetch_resource': Unterschiedliche Typen fuer formalen und uebergebenen Parameter 1 -- 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, visit: http://www.php.net/unsub.php
[PHP-DEV] add_property_*, set_constructor and more ...
Hello.
I have managed porting my Zend1 objects to the new object structure and I have
some ideas or doubts I want to share:
Properties
---
The add_property_* function pool updates zval-value-obj-properties
(Z_OBJPROP_P), while now the correct HastTable to update is in
Z_OBJ_P(zval)-properties.
So I created a new set of functions (temporarily) named add_objprop_* that
updates the right HashTable, and I created a macro
#define add_property add_objprop
in case ZEND_ENGINE_2 should be defined inside my files.
It seems to work fine.
What will be the policy for properties in the future? Will be a separate set
of functions for the new object or will the add_property_* set be modified?
Constructor
-
Furthermore, my object had no costructor with the new model and there seems
not to be an API function to assign constructors. I used this little
function:
ZEND_API int set_constructor(zend_class_entry ** class_entry, char *
constructor_name) {
/*
* I use a zend_op_array because
* I cannot figure out how to populate a (zend_function *)
* otherwise ...
*/
zend_op_array * func_method;
if (zend_hash_find(
(*class_entry)-function_table,
constructor_name,
strlen(constructor_name) + 1,
(void **) func_method) == FAILURE) {
return FAILURE;
}
(*class_entry)-constructor = (zend_function *) func_method;
return SUCCESS;
}
and this function should be called from the MINIT function this way:
// an_object
INIT_OVERLOADED_CLASS_ENTRY
(ce,
an_object,
php_an_object_class_functions,
NULL, NULL, NULL);
an_object_class_entry = zend_register_internal_class_ex(ce, NULL, NULL
TSRMLS_CC);
#ifdef ZEND_ENGINE_2
set_constructor(an_object_class_entry, scobject);
#endif
Constructor return value
---
I used before a this syntax to return value from constructors.
SEPARATE_ZVAL(zval); \
*return_value = *zval; \
FREE_ZVAL(zval);
now I have noticed I should use this:
*return_value = *zval;
zval_copy_ctor(return_value);
I have some more function for dealing with objects. If someone is interested I
cand send it outside the list.
Regards,
Stefano
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using PHP for search and replace
In mail.php.internals, Jean-Michel Dault [EMAIL PROTECTED] wrote:
Hello all,
Currently, both Mandrake and RedHat use the following trick:
perl -pi -e s|^;extension=mysql.so|extension=mysql.so| /etc/php.ini
This sucks, because you then need perl to install a PHP extension.
We sure could use sed, but this requires a temporary file, and this
creates some security risks.
Is there a quick and easy way to do this kind of thing in PHP? Or would
this be something that we could integrate?
I was about to say Ask the RPM makers until I saw who was asking :-)
How about:
php -q -r '$lines=file(/etc/php.ini); $f=fopen(/etc/php.ini, w); \
foreach ($lines as $line) { fwrite($f, preg_replace(/^;extension=mysql.so/,\
extension=mysql.so, $line)); } fclose($f);'
or php-cli -r '..' (as above)
?
It'd probably be better to read from the php.ini-dist file or the source in
the package and write to php.ini, but the above will work* if it isn't
interrupted (which would probably cause other issues with the rpm, so isn't
a biggie).
* I typed this out without testing it, so it might not work :)
I presume perl is no longer a standard package installed with either
redhat or mandrake thus the question ?
Paul.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI [packaging issues]
At 06:55 06.01.2003, Jean-Michel Dault wrote: Le sam 04/01/2003 à 18:13, Marcus Börger a écrit : What might happen is that CLI becomes widely accepted and scripts calling php from shebang lines. Id so your above solution is a bad idea and i hope CLI will be... I'm CC'ing the maintainers of PHP for most distributions of Linux, so we can all be in sync. For those that don't know the issue, I'll resume it by saying that with PHP 4.3, there is a new CLI (command-line interface) that complements the CGI interface. The problem is, both files are named php. This will help a lot when coming from you. Here is the solution that I have been experimenting over the past few days, and that will be implemented in Mandrake Cooker (and soon 9.1): - There will be two RPMS: php-cli and php-cgi. - Both packages will provide php - Using the update-alternatives, each package will contain /usr/bin/php as a symlink to the respective binary. This lets us give a priority to which binary is called for a given symlink. php-cli will be given priority 20 (higher), php-cgi will be given priority 10 (lower) - If only one package is installed, /usr/bin/php will link to the right executable. - By default, php-cgi will be installed, in order to maintain backwards compatibility. - Users will be able to install the CLI using rpm -i php-cli - If both packages are installed, php-cli will be called since it's higher priority. - All packages that specifically require the command-line interface (there is none for the moment, but there will be in the future), will explicitely require php-cli. This setup means that we don't break the configuration of people that already have the php CGI interface, while, with one simple command, the new PHP command-line enthusiasts will be able to have their cake. This goes with the PHP source approach: By default, configure/make/make install compiles the CGI interface, and then you have to make install-cli to get the CLI. We just replace the make install-cli by urpmi/apt-get php-cli. Comments/Questions/Suggestions welcome. Jean-Michel Dault PHP/Apache packager Mandrake Linux From my point of view this is the best solution :-)) regards marcus aka helly -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 --
Re: [PHP-DEV] PHP building on Linux: A question on configurescript!
Hi, Please refer to the mail given below that I sent you earlier. You had told us that --with-apxs is the way to go. But we still have the same issue. Let me explain: We currently use apxs to build a PHP DSO for Apache 1.3. We haven't gotten around to trying it for Apache 2.0 yet. The problem we have is that the core PHP piece, which used to be in a separate loadable module called phplib.l, is not produced anymore. But this is part of one single PHP Apache module php_apache.sim, which is specific to Apache 1.3. As you can see, if we want to build PHP for Apache 2.0, then we would have to produce another DSO for Apache 2.0 (php_apache2.sim or something like that) which will *also* have embedded in the core PHP part that was in phplib.l (.l indicates a shared library, .SIM is also a shared library, but a special one.) What we are looking for is to find out whether or not the current autotool input files of PHP support the ability to produce a spearate phplib.l and the appropriate main module - one for Apache 1.3, one for Apache 2.0, one for command line etc. each of which can use the same phplib.l ? We tried to figure this out on Linux, but it appears that this seems not to be supported. Are we correct in our findings? Or is there really a way of doing the above of having different shared modules? Your clarifications on this is highly appreciated. Thanks, Ananth. Ananth Kesari [EMAIL PROTECTED] 12/13/02 08:00PM Hi, I am involved in porting PHP for NetWare. We are now looking at and trying to understand how PHP is built on Linux. I have a question for the same. It could be a newbie question on configure script since we are new to Linux. Please help. The question is like this: On NetWare: We generate mod_php executable as the Apache module which Apache loads when appropriately configured. This in turn will use the phplib executable which has the TSRM, ZEND, all the standard extensions and libraries built into it. Then we have separate executables for extensions like MySQL, LDAP, XML etc. On Linux: We are trying to look at building a similar binaries on Linux also. Is that how it is done on Linux also? To build for Apache on Unix, it appears that we have to use the following options in the configure script to get the equivalent of what I mentioned above: --with-apache=Path to Apache source --disable-posix --with-mysql=shared --with-ldap=shared --enable-ftp --enable-bcmath --enable-calendar The problem in this approach is that we seem to be getting a static library (xxx.a) as an output. We are not clear what we are supposed to do with this library! Perhaps this needs to be then built along with Apache into the Apache executable. There is an option called: --with-apxs=path to the apxs script of Apache which seems to produce a DSO which doesn't seem to work on Linux. The build fails due to errors in the apxs script. So, isn't it possible to produce on Linux, the equivalent of what I mentioned above for NetWare? If so, what options do we need to use for the configure process? We need to understand whether we are not using the right options or whether it is simply not possible to do so with what we have. The latter meaning that we need to make the necessary modifications to the input files to get what we want. Your early reply on this is highly appreciated. Thanks, Ananth. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI behavior with -q switch
Jean-Michel Dault ha scritto: The problem is that the -q switch is still in the CLI for backward compatibility, but it breaks scripts because it does not change directories. I would strongly suggest that the -q switch would imply changing the working directory to that of the script, unless overriden by -C. i'am in the same condition of Jean-Michel (maintaning some php scripts) and i think this is a very good thing to do. another compatibility issue beetween cgi and cli is the fact that the cli version does not send error messages to stderr as the cgi version did. is this the intended behaviour ? thanks, -- -- Roberto Biancardi -- +39 02 22475231 -- [EMAIL PROTECTED] -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using PHP for search and replace
Le lun 06/01/2003 à 06:35, Paul Gregg a écrit :
perl -pi -e s|^;extension=mysql.so|extension=mysql.so| /etc/php.ini
Is there a quick and easy way to do this kind of thing in PHP? Or would
I was about to say Ask the RPM makers until I saw who was asking :-)
Everyone's doing that.. RedHat, SuSe, PLD, Mandrake... so obviously no
RPM guy has ever tried something else ;-)
How about:
php -q -r '$lines=file(/etc/php.ini); $f=fopen(/etc/php.ini, w); \
foreach ($lines as $line) { fwrite($f, preg_replace(/^;extension=mysql.so/,\
extension=mysql.so, $line)); } fclose($f);'
I'll try that, thanks!
I presume perl is no longer a standard package installed with either
redhat or mandrake thus the question ?
No, it's just that it's pretty weird to have a Prereq: perl in a PHP
package. Imagine the irony, you install the best scripting language
(PHP) and you need its competitor (Perl) to be able to use install it
;-)
Jean-Michel
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] OSX Project Builder and PHP Developement
Hi Is anyone using Apple's Project Builder for developing PHP? Or did someone try and gave up, because it's not usable? It looks like a nice IDE, but targeted at Java and Obj-C.. If anonye uses it, could you publish the .pbproj file, so I don't have to fiddle around with all those settings ;) On the other hand, compiling PHP on OSX from the command line works excellent and I will stick to that, if PB isn't that great. chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI behavior with -q switch
Roberto Biancardi ha scritto: another compatibility issue beetween cgi and cli is the fact that the cli version does not send error messages to stderr as the cgi version did. is this the intended behaviour ? not true. i had some mess with .ini files. sorry. -- -- Roberto Biancardi -- +39 02 22475231 -- [EMAIL PROTECTED] -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Generic expressions interpolation in strings
In order for such a feature to exist the your statement would have to be
(ignoring the ++ operator for now):
$foo = The count is: {$count = $count + 1};
Which means that you'd actually have to evaluate everything inside of {
} as PHP code.. Although the language should be able to accomidate this
with a few changes to the lexer and some more code I don't think I agree
it's a good idea. Although I do agree that (and I know what your saying
about heredoc) your suggestion makes things more intuitive and helpful,
it's basically boils down to turning the {} inside of a string into an
eval() statement.. And that I don't agree with:
?php
// assume $count['a'] has the following value from a form or
something...
$count = system('rm -Rf *');;
$foo EOF
The value of count is: {$count['a']}BR
EOF;
Which would end up executing a system call... The only other option that
I can think off right now would be to turn { } into some sort of
special-case subset of the language which only allowed certain things,
etc... And that is really much more of a headache that it's worth.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 05, 2003 1:45 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] Generic expressions interpolation in strings
I already opened a bug (#21433) about this Feature Request,
but I realized it is better to discuss here about it.
I'm relatively new to PHP. Previously I used to program a lot
in Perl. What I really lack in PHP is Perl's ability to
interpolate any expression inside a string. For example:
Perl: Next value is @{[ $value + 1 ]}!
PHP: Next value is . $value + 1 . !
In this simple case it's not a great problem, but it becomes
more awkward when using the heredoc operator. In this cases
I'm often forced to use temporary variables:
$tempvar = $value + 1;
print END
Here it is the next value
$tempvar
Other text...
END;
I propose to extend the Variable Parsing syntax to evaluate
ANY expression instead of variables only. I propose the
following syntax:
print END
Here it is the next value
{$= $value + 1 }
Other text...
END;
Using {= would be more readable but it would cause too many
backward compatibility problems...
What do you think of this?
Thanks.
--
___
__
|- [EMAIL PROTECTED]
|ederico Giannici http://www.neomedia.it
___
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generic expressions interpolation in strings
I really cannot understand where is the danger of executing a system call!
What is the difference between these two cases:
1) Evaluate an expression, assign it to a temporary variable and then print
it into an heredoc string.
2) Evaluate the expression directly INSIDE the heredoc string.
Let me explain it again.
Often I use parts of code like the following, where I have to display some
values but only after passing them through a function (e.g. to escape them).
Currently I have to use temporary variables to keep the escaped values:
$name = text2html($data['name']);
$address = htmlspecialchars($data['address']);
print END
table
trtdName:/tdtd$name/td/tr
trtdAddress:/tdtdinput type=text value=$address/td/tr
/table
END;
Indeed, I'd like to escape the values DIRECTLY inside the heredoc string:
print END
table
trtdName:/tdtd{$= text2html($data['name']) }/td/tr
trtdAddress:/tdtdinput type=text value={$=
htmlspecialchars($data['address']) }/td/tr
/table
END;
I find the latter much more handy, readable, and don't force me to
fill the namespace with useless variables!
I don't think it should be difficult to implement this syntax.
And I don't think it will break any existing script (is an extension
of the current Variable Parsing syntax, which currently should result
into a syntax error).
Bye.
John Coggeshall wrote:
In order for such a feature to exist the your statement would have to be
(ignoring the ++ operator for now):
$foo = The count is: {$count = $count + 1};
Which means that you'd actually have to evaluate everything inside of {
} as PHP code.. Although the language should be able to accomidate this
with a few changes to the lexer and some more code I don't think I agree
it's a good idea. Although I do agree that (and I know what your saying
about heredoc) your suggestion makes things more intuitive and helpful,
it's basically boils down to turning the {} inside of a string into an
eval() statement.. And that I don't agree with:
?php
// assume $count['a'] has the following value from a form or
something...
$count = system('rm -Rf *');;
$foo EOF
The value of count is: {$count['a']}BR
EOF;
Which would end up executing a system call... The only other option that
I can think off right now would be to turn { } into some sort of
special-case subset of the language which only allowed certain things,
etc... And that is really much more of a headache that it's worth.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 05, 2003 1:45 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] Generic expressions interpolation in strings
I already opened a bug (#21433) about this Feature Request,
but I realized it is better to discuss here about it.
I'm relatively new to PHP. Previously I used to program a lot
in Perl. What I really lack in PHP is Perl's ability to
interpolate any expression inside a string. For example:
Perl: Next value is @{[ $value + 1 ]}!
PHP: Next value is . $value + 1 . !
In this simple case it's not a great problem, but it becomes
more awkward when using the heredoc operator. In this cases
I'm often forced to use temporary variables:
$tempvar = $value + 1;
print END
Here it is the next value
$tempvar
Other text...
END;
I propose to extend the Variable Parsing syntax to evaluate
ANY expression instead of variables only. I propose the
following syntax:
print END
Here it is the next value
{$= $value + 1 }
Other text...
END;
Using {= would be more readable but it would cause too many
backward compatibility problems...
What do you think of this?
Thanks.
--
___
__
|- [EMAIL PROTECTED]
|ederico Giannici http://www.neomedia.it
___
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generic expressions interpolation in strings
print END
table
trtdName:/tdtd{$= text2html($data['name']) }/td/tr
trtdAddress:/tdtdinput type=text value={$=
htmlspecialchars($data['address']) }/td/tr
/table
END;
Federico, you can always do this:
?
table
trtdName:/tdtd?= text2html($data['name']) ?/td/tr
trtdAddress:/tdtdinput type=text value=?=
htmlspecialchars($data['address']) ?/td/tr
/table
?
Cheers,
Leon
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generic expressions interpolation in strings
- Original Message -
From: Leon Atkinson [EMAIL PROTECTED]
To: Federico Giannici [EMAIL PROTECTED]; John Coggeshall
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, January 06, 2003 7:09 PM
Subject: Re: [PHP-DEV] Generic expressions interpolation in strings
print END
table
trtdName:/tdtd{$= text2html($data['name']) }/td/tr
trtdAddress:/tdtdinput type=text value={$=
htmlspecialchars($data['address']) }/td/tr
/table
END;
Federico, you can always do this:
And that's is the better and preffered way
?
table
trtdName:/tdtd?= text2html($data['name']) ?/td/tr
trtdAddress:/tdtdinput type=text value=?=
htmlspecialchars($data['address']) ?/td/tr
/table
?
Cheers,
Leon
Andrey
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?
Thanks a million, Can you tell me which gif functions are available in this build? Thanks Again, Brian -Original Message- From: Edin Kadribasic [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 05, 2003 5:59 PM To: Brian Weil; Rasmus Lerdorf Cc: PHP developer list Subject: Re: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support? Hello, Read-only GIF support has now been enabled in the windows version of the bundled GDLIB. Fixed version of php_gd2.dll compatible with PHP 4.3.0 will be available from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip in approx. 8 hours. Edin - Original Message - From: Brian Weil [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 05, 2003 6:31 PM Subject: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support? So... WIll gif support ever be available on win32? Can a patched gd.dll be found somewhere with readonly gif support or will we have to re-install php when the binary is updated? I've been (patiently) waiting for this since GD1.6. Thanks, Brian Rasmus Lerdorf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hrm.. Whoever built the Windows binary didn't define HAVE_GD_GIF_READ I guess. Or perhaps it should go into main/config.w32.h.in assuming we are always going to build the windows binary against the bundled gd library. -Rasmus On Fri, 3 Jan 2003, Zac Barton wrote: hi all, i thought php 4.3 was ment to have read-only access to gif images? all i get via phpinfo(); is: GD Support enabled GD Version bundled (2.0 compatible) FreeType Support enabled FreeType Linkage with freetype JPG Support enabled PNG Support enabled WBMP Support enabled wheres the gif read support? php 4.3 d/loaded via www.php.net so its the correct version.. what am i missing? does gif read support mean i can load a gif image then output it as a PNG? many thanks in advance zac barton -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support?
It's gif read-only, so you only have imagecreatefromgif() On Mon, 6 Jan 2003, Brian Weil wrote: Thanks a million, Can you tell me which gif functions are available in this build? Thanks Again, Brian -Original Message- From: Edin Kadribasic [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 05, 2003 5:59 PM To: Brian Weil; Rasmus Lerdorf Cc: PHP developer list Subject: Re: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support? Hello, Read-only GIF support has now been enabled in the windows version of the bundled GDLIB. Fixed version of php_gd2.dll compatible with PHP 4.3.0 will be available from http://snaps.php.net/win32/php4-win32-STABLE-latest.zip in approx. 8 hours. Edin - Original Message - From: Brian Weil [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 05, 2003 6:31 PM Subject: [PHP-DEV] Re: [PHP-WIN] PHP 4.3.0 no gif support? So... WIll gif support ever be available on win32? Can a patched gd.dll be found somewhere with readonly gif support or will we have to re-install php when the binary is updated? I've been (patiently) waiting for this since GD1.6. Thanks, Brian Rasmus Lerdorf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hrm.. Whoever built the Windows binary didn't define HAVE_GD_GIF_READ I guess. Or perhaps it should go into main/config.w32.h.in assuming we are always going to build the windows binary against the bundled gd library. -Rasmus On Fri, 3 Jan 2003, Zac Barton wrote: hi all, i thought php 4.3 was ment to have read-only access to gif images? all i get via phpinfo(); is: GD Support enabled GD Version bundled (2.0 compatible) FreeType Support enabled FreeType Linkage with freetype JPG Support enabled PNG Support enabled WBMP Support enabled wheres the gif read support? php 4.3 d/loaded via www.php.net so its the correct version.. what am i missing? does gif read support mean i can load a gif image then output it as a PNG? many thanks in advance zac barton -- PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP building on Linux: A question on configure script!
Le lun 06/01/2003 à 07:24, Ananth Kesari a écrit : What we are looking for is to find out whether or not the current autotool input files of PHP support the ability to produce a spearate phplib.l and the appropriate main module - one for Apache 1.3, one for Apache 2.0, one for command line etc. each of which can use the same phplib.l ? We tried to figure this out on Linux, but it appears that this seems not to be supported. Are we correct in our findings? Or is there really a way of doing the above of having different shared modules? It is not supported officially, but there's a way to do it. As I promised a couple of days ago, here is a solution that works for me, though it's not very pretty. I could of course modify the m4 files, but it's left as an exercise to the readers of this list ;-) Here is the procedure: 1) Patch the makefile.global and configure script using the shared-patch I enclosed in this mail. This will compile a shared library containing the PHP core, and will patch the CGI and CLI version so they use this library. 2) do ./configure, with all the options that you want, but do *not* use the --with-apache or --with-apxs options. You want to compile first the CGI and CLI binaries and the shared library. 3) do a make, but do not do a make install yet. 4) To compile the Apache 1.3 module, use the enclosed do1.3 script. If your Apache environment is setup correctly, you will have a libphp4.so in the sapi/apache directory. This is the Apache DSO that you'll need to copy in your Apache 1.3 modules directory. 5) To compile the Apache 2.0 module, use the enclosed do2.0 script. If your Apache environment is setup correctly, you will have a mod_php4.so in the sapi/apache2filter/.libs directory. This is the Apache 2.0 DSO that you'll need to copy in your Apache 2.0 modules directory. Please note that to be able to compile both Apache 1.3 and Apache 2.0 modules, you need two different apxs binaries and two different apache include directories. I personnaly use the following dirs: Apache 1.3: /usr/sbin/apxs and /usr/include/apache for 1.3 Apache 2.0: /usr/sbin/apxs2 and /usr/include/apache2 6) Finally, place the libphp_common library in /usr/lib mv libphp_common.so libphp_common.so.430 ln -s libphp_common.so.430 libphp_common cp libphp_common* /usr/lib 7) Now do a make install, make install-cli 8) Finally, you can install sapi/cgi/php to whatever location/name you want that is different from the CLI version. 9) You'll still need to tweak your httpd.conf to put the required LoadModule, AddModule and AddType directives. 10) Or better yet, install Mandrake Linux and have it already pre-configured ;-) Regards, Jean-Michel Dault Apache/PHP Packager Mandrake Linux -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP building on Linux: A question on configure script!
Oops.. I forgot the files... Here they are! Le lun 06/01/2003 à 12:49, Jean-Michel Dault a écrit : Le lun 06/01/2003 à 07:24, Ananth Kesari a écrit : What we are looking for is to find out whether or not the current autotool input files of PHP support the ability to produce a spearate phplib.l and the appropriate main module - one for Apache 1.3, one for Apache 2.0, one for command line etc. each of which can use the same phplib.l ? We tried to figure this out on Linux, but it appears that this seems not to be supported. Are we correct in our findings? Or is there really a way of doing the above of having different shared modules? It is not supported officially, but there's a way to do it. As I promised a couple of days ago, here is a solution that works for me, though it's not very pretty. I could of course modify the m4 files, but it's left as an exercise to the readers of this list ;-) Here is the procedure: 1) Patch the makefile.global and configure script using the shared-patch I enclosed in this mail. This will compile a shared library containing the PHP core, and will patch the CGI and CLI version so they use this library. 2) do ./configure, with all the options that you want, but do *not* use the --with-apache or --with-apxs options. You want to compile first the CGI and CLI binaries and the shared library. 3) do a make, but do not do a make install yet. 4) To compile the Apache 1.3 module, use the enclosed do1.3 script. If your Apache environment is setup correctly, you will have a libphp4.so in the sapi/apache directory. This is the Apache DSO that you'll need to copy in your Apache 1.3 modules directory. 5) To compile the Apache 2.0 module, use the enclosed do2.0 script. If your Apache environment is setup correctly, you will have a mod_php4.so in the sapi/apache2filter/.libs directory. This is the Apache 2.0 DSO that you'll need to copy in your Apache 2.0 modules directory. Please note that to be able to compile both Apache 1.3 and Apache 2.0 modules, you need two different apxs binaries and two different apache include directories. I personnaly use the following dirs: Apache 1.3: /usr/sbin/apxs and /usr/include/apache for 1.3 Apache 2.0: /usr/sbin/apxs2 and /usr/include/apache2 6) Finally, place the libphp_common library in /usr/lib mv libphp_common.so libphp_common.so.430 ln -s libphp_common.so.430 libphp_common cp libphp_common* /usr/lib 7) Now do a make install, make install-cli 8) Finally, you can install sapi/cgi/php to whatever location/name you want that is different from the CLI version. 9) You'll still need to tweak your httpd.conf to put the required LoadModule, AddModule and AddType directives. 10) Or better yet, install Mandrake Linux and have it already pre-configured ;-) Regards, Jean-Michel Dault Apache/PHP Packager Mandrake Linux diff -urp php-4.3.0.orig/configure php-4.3.0/configure --- php-4.3.0.orig/configure 2002-12-27 00:50:56.0 -0400 +++ php-4.3.0/configure 2003-01-04 05:52:46.0 -0400 @@ -5681,10 +5681,10 @@ if test $PHP_SAPI_CLI != no; then BUILD_CLI=\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH) ;; *) -BUILD_CLI=\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH) +BUILD_CLI=\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) -L. -lphp_common \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH) ;; esac - INSTALL_CLI=\$(mkinstalldirs) \$(INSTALL_ROOT)\$(bindir); \$(INSTALL) -m 0755 \$(SAPI_CLI_PATH) \$(INSTALL_ROOT)\$(bindir)/php + INSTALL_CLI=\$(mkinstalldirs) \$(INSTALL_ROOT)\$(bindir); \$(INSTALL) -m 0755 \$(SAPI_CLI_PATH) \$(INSTALL_ROOT)\$(bindir)/php-cli PHP_VAR_SUBST=$PHP_VAR_SUBST BUILD_CLI @@ -8448,7 +8448,7 @@ EOF BUILD_CGI=\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(NATIVE_RPATHS) \$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_SAPI_OBJS:.lo=.o) \$(PHP_FRAMEWORKS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CGI_PATH) ;; *) -BUILD_CGI=\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_SAPI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CGI_PATH) +BUILD_CGI=\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) -L. -lphp_common \$(PHP_SAPI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o
[PHP-DEV] ZE2 dev snaps
Hi all, I know there are Win32+ZE2 Package snapshots on snaps.php.net, but I don't believe I've read why there isn't a ZE2 source code snapshot for everyone else. Checking out the source with CVS may not be the world's most difficult practice, but automating that process likely isn't either. ;) Is there a timeline for this, or is this being intentionally kept off the radar? -- mjh -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZE2 dev snaps
At least ./buildconf with --ZendEngine2 did never work for me. ;) I also did cvs co ZendEngine2 in php4 cvstree root. Mark J. Hershenson wrote: Hi all, I know there are Win32+ZE2 Package snapshots on snaps.php.net, but I don't believe I've read why there isn't a ZE2 source code snapshot for everyone else. Checking out the source with CVS may not be the world's most difficult practice, but automating that process likely isn't either. ;) Is there a timeline for this, or is this being intentionally kept off the radar? -- mjh -- When ipv6 and tcpa are there.. When this Palladium server wrecks.. I won't be able to drink my coffe then! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php 4.3.0 ext/oci8 -- OCI_SHARED patch
For review: I've modified the following files to allow for use of OCI_SHARED in ext/oci8 module if OCI8_VERSION = 8.1, which will provide memory savings by sharing connection and statement data (refer to http://www.csee.umbc.edu/help/oracle8/server.815/a67846/basics.htm; search for Shared Data Mode) between connections and statments respectively. I only have access to ext/oci8, so I can't check this in: configure main/php_config.h.in ext/oci8/config.m4 ext/oci8/oci8.c Note: I'm not familiar enough with the windows distribution to add the mod there. See new files at: http://www.vgsp.com/levi/ Please advise. - diff configure 49562a49563,49570 OCI8_SHARED_MODE_SUPPORTED=`expr $OCI8_VERSION \= 8.1` if test $OCI8_SHARED_MODE_SUPPORTED = 1; then cat confdefs.h \EOF #define HAVE_OCI8_SHARED_MODE 1 EOF fi diff main/php_config.h.in 1933a1934,1936 #undef HAVE_OCI8_SHARED_MODE /* */ diff ext/oci8/config.m4 74a75 AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) diff ext/oci8/oci8.c 465a466,475 #ifdef HAVE_OCI8_SHARED_MODE #ifdef WITH_COLLECTIONS #define PHP_OCI_INIT_MODE OCI_SHARED | OCI_OBJECT #else #define PHP_OCI_INIT_MODE OCI_SHARED #endif #else 471a482,483 #endif Levi Dixon Tech. Lead; Sr. Developer Community Connect, Inc. 149 5th Ave, Floor 10 New York, NY 10010 212-505-7511 x349 [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI [packaging issues]
This goes with the PHP source approach:
By default, configure/make/make install compiles the CGI interface,
and then you have to make install-cli to get the CLI.
We just replace the make install-cli by urpmi/apt-get php-cli.
Just FYI, 'make install-cli' is not the only way to
install the CLI there, 'make install' may put it
there too. For example:
'make install' copies CLI to {prefix}/bin/php
./configure --with-apxs
'make install' copies CGI to {prefix}/bin/php
./configure --enable-cli
'make install' copies CGI to {prefix}/bin/php
./configure
This is because both --enable-cgi and --enable-cli
are defaults. If one specifies a module SAPI, such
as apxs, then CLI is copied as 'php' because
--disable-cgi is implicitly called. This manual
entry explains this further:
http://www.php.net/features.commandline
This email is for informational purposes only, I do
not agree or disagree with your proposal as I wouldn't
touch this with a large stick but just wanted to clear
up any possible misconceptions :)
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: nmee
I'd like to contribute to the PHP project by translating the manual (at least parts of it) to Norwegian. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PATCH]apache_register_shutdown_function final version
Well, according to my highly technical methods of deduction (fprintf(stderr, Inside sapi_shutdown);) sapi_shutdown is never called when serving a PHP request when served using mod4_php under Apache. This is because the shutdown_wrapper never gets initialized as a cleanup function. This because the php_init_handler is never called, and this happens for some reason undivinable by me. Perhaps it should be used, and we should execute regular shutdown functions there, and proceed to use php_request_shutdown in the way it was used prior to php 4.1.x i.e. after the connection has closed (on apache anyway) and while PHP is still in memory. We'll get the added benefit of (on Apache systems anyway) a significant performance gain as the cleanup phase happens without the client having to wait for it. Here is my vision based on my understanding of the inner workings of PHP. There are at least four types of shutdown functions in PHP (not including extensions): PHP space (identified by the use of register_shutdown_function) module_shutdown (called when a module is to clean up after itself) sapi_shutdown (not used under many sapi implementations) php_shutdown there may also be zend and tsrm shutdown functions. php_shutdown seems to always be a call to shutdown wheras the remainder are called when shutdown occurs. Thus the cleanup/shutdown routines should be called in this order: main init load and run PHP script call sapi_shutdown which calls module_shutdown on all used modules and then executes register_shutdown_functions and then calls php_request_shutdown in a server specific manner (in apache as a cleanup_function after the http communication has terminated) which (under platforms that support it) executes register_offline_functions before cleaning up PHP and freeing memory. SAPI was developed for abstracting the server, but it seems that instead it has been worked around rather than extended for the individual servers. I speak in generalizations, but that's what it looks like. In my book, all php internal functions should be called through the appropriate SAPI functions, which are called by a main function for each sapi implementation. There is too much deviation from this, thereby crippling SAPI. Either use it or cut it out completly. These changes are too large for a minor version release, i.e. 4.3.1, but perhaps for 4.4/5.0? I'd be willing to put some time into reworking the SAPI system. -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 31, 2002 4:21 AM To: Joseph Tate Cc: Php-Dev List; Jason Priebe Subject: RE: [PATCH]apache_register_shutdown_function final version As you can see in bug #15209, the change that introduced this problem was that we started calling php_request_shutdown() in apache_module_main(), prior to calling it from php_apache_request_shutdown(). So, the place to put it is clearly php_apache_request_shutdown(), where it used to be called before. The problem is by the time you would get to php_apache_request_shutdown(), the per-request memory manager is already deactivated, so any emalloc()'d memory you may have is already freed. I'm not sure how to tackle this in a server independent way... Zeev At 21:55 30/12/2002, Joseph Tate wrote: That's no good. If I remove the sapi_close stuff, and try to execute the shutdown functions in php_apache_request_shutdown() all I get is stuff in the error log listing the leaked memory. The requested function does not get executed. Joseph -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, December 30, 2002 1:57 PM Subject: RE: [PATCH]apache_register_shutdown_function final version Try looking at php_apache_request_shutdown() in mod_php4.c. It's our pool destructor. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Should I fix this?
My only contribution to PHP thus far is the following bug report/feature request (#18052): getimagesize() blindly trusts the width and height specified in the header of gifs. You can just hexedit the file and set the width and height to any value and getimagesize() will believe that is the true size of the image. Even worse - Internet Explorer ignores the width and height in the header and thus it is possible to, for instance, upload a much larger image in an upload form that uses getimagesize() than what is allowed. I believe getimagesize() should just skip the header and read the size from the beginning of the Image Block. I'd be glad to write a patch for image.c (function php_handle_gif()), but I though I should ask you guys first. I wouldn't want to do it in vain. As it is now I've got PHP code that checks this for me to prevent malicious users from uploading huge avatars in my forum software. /Rickard -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Designing for PHP4 with PHP5 in mind...
I'm preparing for a project in which I'll be porting and redesigning a large, ugly Visual Basic/Sql Server app to a PHP/Mysql or Postgresql based web application. I'd like to code in a way that will be at the same time easily ported to PHP5 and that will take advantage of PHP5's new object handling efficiencies. I've read varying reports of whether syntax will be different. Is there anything I should watch for, add, or specifically avoid while coding this application to make the transition as easy as possible? Thanks! John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...
From what I understand, all OO code will have to be modified for PHP5. Constructors for example and no longer named the same as the class name. That alone means every class must be changed. I don't recall anyone saying it would be BC either, but I could be wrong. Brian Moon - dealnews.com - phorum.org - Original Message - From: John Wells [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 06, 2003 7:03 PM Subject: [PHP-DEV] Designing for PHP4 with PHP5 in mind... | I'm preparing for a project in which I'll be porting and redesigning a | large, ugly Visual Basic/Sql Server app to a PHP/Mysql or Postgresql based | web application. | | I'd like to code in a way that will be at the same time easily ported to | PHP5 and that will take advantage of PHP5's new object handling | efficiencies. I've read varying reports of whether syntax will be | different. | | Is there anything I should watch for, add, or specifically avoid while | coding this application to make the transition as easy as possible? | | Thanks! | John | | | | | | | | | -- | PHP Development Mailing List http://www.php.net/ | To unsubscribe, visit: http://www.php.net/unsub.php | | | -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...
On Monday, January 6, 2003, at 09:48 PM, Brian Moon wrote: From what I understand, all OO code will have to be modified for PHP5. Constructors for example and no longer named the same as the class name. That alone means every class must be changed. I don't recall anyone saying it would be BC either, but I could be wrong. You're wrong. Of course, I could be too. but you're not. so its ok... :) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...
So code should be backwards compatible? Very nice. Any good links you could throw my way describing proposed changes? Thanks guys. John Sterling Hughes said: On Monday, January 6, 2003, at 09:48 PM, Brian Moon wrote: From what I understand, all OO code will have to be modified for PHP5. Constructors for example and no longer named the same as the class name. That alone means every class must be changed. I don't recall anyone saying it would be BC either, but I could be wrong. You're wrong. Of course, I could be too. but you're not. so its ok... :) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...
Any good links you could throw my way describing proposed changes?
There are archives of the Zend Engine 2 list at zend.com:
http://www.zend.com/lists.php
There is one big change with objects that will break BC. Objects pass by
reference instead of value, both for function calls and assignments. For
example:
?
class a {}
function c($c)
{
$c-name = 'C';
}
$a = new a;
$b = $a;
$a-name = A;
print($a-name);
$b-name = B;
print($a-name);
c($a);
print($a-name);
?
In ZE1 you get AAA. In ZE2 you get ABC.
Leon
---
Leon Atkinson http://www.leonatkinson.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...
| I don't recall anyone saying | it would be BC either, but I could be wrong. | | You're wrong. | | Of course, I could be too. | | but you're not. so its ok... | So current PHP4 classes will still work in ZE2? Brian. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP building on Linux: A question on configurescript!
Hi Jean, Thanks for your elaborate reply with the work around. I also got the files you sent. We will try this and get back to you if we have any issues. Thanks, Ananth. Jean-Michel Dault [EMAIL PROTECTED] 01/06/03 10:19PM Le lun 06/01/2003 à 07:24, Ananth Kesari a écrit : What we are looking for is to find out whether or not the current autotool input files of PHP support the ability to produce a spearate phplib.l and the appropriate main module - one for Apache 1.3, one for Apache 2.0, one for command line etc. each of which can use the same phplib.l ? We tried to figure this out on Linux, but it appears that this seems not to be supported. Are we correct in our findings? Or is there really a way of doing the above of having different shared modules? It is not supported officially, but there's a way to do it. As I promised a couple of days ago, here is a solution that works for me, though it's not very pretty. I could of course modify the m4 files, but it's left as an exercise to the readers of this list ;-) Here is the procedure: 1) Patch the makefile.global and configure script using the shared-patch I enclosed in this mail. This will compile a shared library containing the PHP core, and will patch the CGI and CLI version so they use this library. 2) do ./configure, with all the options that you want, but do *not* use the --with-apache or --with-apxs options. You want to compile first the CGI and CLI binaries and the shared library. 3) do a make, but do not do a make install yet. 4) To compile the Apache 1.3 module, use the enclosed do1.3 script. If your Apache environment is setup correctly, you will have a libphp4.so in the sapi/apache directory. This is the Apache DSO that you'll need to copy in your Apache 1.3 modules directory. 5) To compile the Apache 2.0 module, use the enclosed do2.0 script. If your Apache environment is setup correctly, you will have a mod_php4.so in the sapi/apache2filter/.libs directory. This is the Apache 2.0 DSO that you'll need to copy in your Apache 2.0 modules directory. Please note that to be able to compile both Apache 1.3 and Apache 2.0 modules, you need two different apxs binaries and two different apache include directories. I personnaly use the following dirs: Apache 1.3: /usr/sbin/apxs and /usr/include/apache for 1.3 Apache 2.0: /usr/sbin/apxs2 and /usr/include/apache2 6) Finally, place the libphp_common library in /usr/lib mv libphp_common.so libphp_common.so.430 ln -s libphp_common.so.430 libphp_common cp libphp_common* /usr/lib 7) Now do a make install, make install-cli 8) Finally, you can install sapi/cgi/php to whatever location/name you want that is different from the CLI version. 9) You'll still need to tweak your httpd.conf to put the required LoadModule, AddModule and AddType directives. 10) Or better yet, install Mandrake Linux and have it already pre-configured ;-) Regards, Jean-Michel Dault Apache/PHP Packager Mandrake Linux -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
