Re: [PHP-DEV] T1lib thread safety
On Fri, 12 Apr 2002 22:00:12 -0700 (PDT), Rasmus Lerdorf wrote: Just the tip of the iceberg. There are a bunch of libraries that PHP can talk to that are not threadsafe. It's going to take a while before Apache2+PHP is going to be useful. Maybe we need to make a list of libraries that indicates which are thread safe which are not. What about the other SAPIs? There are 9 that specify PHP_BUILD_THREAD_SAFE. Don't they break too? For GD specifically, yes we can put in some mutexes as I earlier today put a copy of the GD library into PHP CVS so we can fiddle with it and distribute our own modified GD with PHP. I was actually thinking of just the GD PHP extension as the GD library itself doesn't call t1lib. It's the ImagePS* functions that do. On Sat, 13 Apr 2002, Brian Havard wrote: While doing some testing with Apache 2.0.35+PHP4.2.0RC3 I'm getting random crashes in T1_LoadFont(). Looking through the t1lib source (v1.3.1) I see frequent use of global variables which suggests it isn't thread safe. Is this a known problem? Maybe some mutexes in GD would help -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T1lib thread safety
Just the tip of the iceberg. There are a bunch of libraries that PHP can talk to that are not threadsafe. It's going to take a while before Apache2+PHP is going to be useful. Maybe we need to make a list of libraries that indicates which are thread safe which are not. What about the other SAPIs? There are 9 that specify PHP_BUILD_THREAD_SAFE. Don't they break too? Yup -R -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
* Ken Egervari wrote: Like I said, I think its time PHP started moving forward and developed a new vision for itself and the community. This is one of the things I'm missing: in my opinion, PHP needs to have a precise roadmap (like Mozilla has for example) what will come for PHP 5, 5.1, 5.2 and so on... Jim's argument about using ext/java: I haven't used this extension until now, but developers told me that this extension is not very stable and not really recommendable for productive use (memory leaks, extension hasn't been further developed for more than a year etc.). Could anyone disprove this? Björn. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
On Sat, Apr 13, 2002 at 08:23:14AM +0200, Björn Schotte wrote : * Ken Egervari wrote: Like I said, I think its time PHP started moving forward and developed a new vision for itself and the community. This is one of the things I'm missing: in my opinion, PHP needs to have a precise roadmap (like Mozilla has for example) what will come for PHP 5, 5.1, 5.2 and so on... Jim's argument about using ext/java: I haven't used this extension until now, but developers told me that this extension is not very stable and not really recommendable for productive use (memory leaks, extension hasn't been further developed for more than a year etc.). Could anyone disprove this? Probably not :) But remedy is on it's way as work has begun on a general RPC class for PHP5 which (should) replace ext/com, ext/java and such. - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Mind if I MFH ? What QA did you do on it? the usual? ah... none :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
On Fri, Apr 12, 2002 at 07:32:47PM -0400, medvitz wrote: The issue I have with PHP is that the people in charge have reasons for not implementing performance enhancements in the base code. They charge a fair amount for add-ons that increases performance drastically. I could actually argue that extensibility and performance on the back end aren't what they should be for this reason. Not that I want to make enemies here, but I think this is a realistic criticism. Not to mention that the Qt license that is used prevents anyone from making extensions and selling them w/o an additional license from the Zend people. So they are able to make money off of the hard work of all of the module contributors, which I think really blows. So if i understand what your saying you don't like that fact the Zend had write an (very) good engine for PHP4 and now is making some money with it?? Don't forget Zend is a commercial company that is doing a lot for the open source community. Without them you didn't had PHP4! Without all the Zend optimalisations (but with the free Zend Optimzer (You've installed it, right?!)) PHP4 has a good performance. With the money they make with their products like Zend Encoder, Zend Cache, etc they can continue developing on the Zend Engine. They don't force you to but their products. They only say that they can really speed up your code. Companies where i work (a official gold microsoft partner ;-( ) has also bought the Zend products. My boss thinks the Zend products are very cheap in comparisment with Microsoft products. Microsoft is doing the same thing. They provide you with a 'free' IIS webserver, but they have also products that enhance IIS like Commerce Server, Content Server, etc. The fact that a commercial company like Zend is working on PHP is for a large number of companies very important. Most open-source projects don't have a proper helpdesk. Zend is providing a very good helpdesk. But all this have two sides. While we (PHP developers) build upon PHP4, and make money with the applications we write with it. And Zend is making money with other Zend products and they make sure PHP is good enough for companies. So don't trap Zend into the ground. Because of them you can program OOP in PHP! That all from me.. Dave Mertens -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
On Sat, Apr 13, 2002 at 12:40:49AM -, Jim Winstead wrote: yes! the new build system that sascha introduced wasn't a move forward. stig (and the large cast of others) working on building the pear infrastructure aren't moving forward. rasmus is standing firm as he looks at integrating the gd library more tightly into php. andi (and others) are blocking progress with all that work on the new zend engine. i wish derick and jani would stop building things like the build tracker at qa.php.net to make the qa process go smoother. i wish yasuo would stop working on the postgresql and session extensions and just give it a rest. that crazy andrei, creating things like the aggregate and overload extensions -- he needs to stop holding us back! don't get me started about wez and all that damn streams stuff! (do i need to continue?) +1000!!! Dave Mertens (You should become a book writer Jim ;-) ) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone wrote persistent variable extension?
Hello, On Fri, 12 Apr 2002, medvitz wrote: I'm currently looking into an extension that would allow both persistent variables, as well as persistent functions. At this point I'm still going through the internals to determine the feasibility of such an extension. I dont want to plug, but SRM can already do this: http://www.vl-srm.net/doc/features.remote-functions.php The documentation still need to be written, but that will follow soon. Derick --- Did I help you? Consider a gift: http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] domxml nightmare and suggestion
Hi In the last weeks, whenever i read some comments about php and what is bad about it (besides all the good points :) ), domxml seems to be one of the top issues... Personally I don't have much problems with this extension, but missing docu and the API as a moving target, is something which worries a lot of people. But one of the weakest things about domxml is IMHO that it promises a DOM-API, which it does not provide very consitently and a lot of functionality is still missing. With all this points, i'd like to start a discussion about starting from scratch with the DOM-API in PHP. Maybe creating a new extension to avoid problems with all the people using domxml already (and therefore not relying on keeping the old API). Furthermore, to make the task in implementing a full w3c-DOM-API a lot easier, i would suggest, we would use libgome2 (http://phd.cs.unibo.it/gdome2/) as the underlying library. gdome2 is based on libxml2, but provides a W3C-DOM level2 implementation (not like libxml2, which has it's own DOM-implementation). The only disadvantage is, that it needs libglib as well, so we would add another library to the prerequisites for domxml... (BTW, libgdome2 seems to be compiling under Windows as well) Ideas, thoughts, etc? chregu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re[3]: [PHP-DEV] Let's fork GD!
Hi, why not replace GD by imagemagick which is better anyway? Have you looked under the skirts of ImageMagick? It is one of the poorest-written libraries I have seen. Have you ever tried to do something productive with GD? It is one of the poorest tools I have ever seen. Seriously: imagemagick can do *ALOT* more than GD. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
On Sat, Apr 13, 2002 at 12:46:56PM +0200, Daniel Lorch wrote: why not replace GD by imagemagick which is better anyway? Have you looked under the skirts of ImageMagick? It is one of the poorest-written libraries I have seen. Have you ever tried to do something productive with GD? It is one of the poorest tools I have ever seen. Seriously: imagemagick can do *ALOT* more than GD. If you think that imagemagick is great, so don't you write an extention for it yourself. Other developers can deside on buildtime which image library they use. But to be onest with you, i don't have any problems with PHP/GD. Only building GD with PHP is sometimes a nightmare, but therefor we have systems management ;-) Dave Mertens -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
* Daniel Lorch wrote: Have you ever tried to do something productive with GD? See http://www.aditus.nu/jpgraph/ (yes, Vagrant seems to be the counterpart of JPGraph regarding Imlib compatibility and general complexity, but I think JPGraph ist the better one) -- PHP-Support * realitätsnahe Performance-Messungen mit Code-Analyse Webapplikationsentwicklung * PHP-Schulungen * Consulting 0700-THINKPHP -*- [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/exif exif.c
Sure i do and it worked fine for all tests!?
marcus
At 00:02 13.04.2002, you wrote:
sniper Fri Apr 12 18:02:30 2002 EDT
Modified files:
/php4/ext/exif exif.c
Log:
Fix the build.
# Marcus, do you TEST build at all before you commit?!
Index: php4/ext/exif/exif.c
diff -u php4/ext/exif/exif.c:1.89 php4/ext/exif/exif.c:1.90
--- php4/ext/exif/exif.c:1.89 Fri Apr 12 12:35:56 2002
+++ php4/ext/exif/exif.cFri Apr 12 18:02:28 2002
-17,7 +17,7
+--+
*/
-/* $Id: exif.c,v 1.89 2002/04/12 16:35:56 helly Exp $ */
+/* $Id: exif.c,v 1.90 2002/04/12 22:02:28 sniper Exp $ */
/* ToDos
*
-107,9 +107,7
};
/* }}} */
-#define EXIF_VERSION 1.3 $Id: exif.c,v 1.89 2002/04/12 16:35:56 helly Exp $
-
-ZEND_DECLARE_MODULE_GLOBALS(exif)
+#define EXIF_VERSION 1.3 $Id: exif.c,v 1.90 2002/04/12 22:02:28 sniper
Exp $
/* {{{ PHP_MINFO_FUNCTION
*/
-132,6 +130,8
char * decode_jis_be;
char * decode_jis_le;
ZEND_END_MODULE_GLOBALS(exif)
+
+ZEND_DECLARE_MODULE_GLOBALS(exif)
#ifdef ZTS
#define EXIF_G(v) TSRMG(exif_globals_id, zend_exif_globals *, v)
--
PHP CVS 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] domxml nightmare and suggestion
On Sat, Apr 13, 2002 at 12:41:44PM +0200, Christian Stocker wrote: top issues... Personally I don't have much problems with this extension, but missing docu and the API as a moving target, is something which worries a lot of people. But one of the weakest things about domxml is IMHO that it promises a DOM-API, which it does not provide very consitently and a lot of functionality is still missing. With all this points, i'd like to start a discussion about starting from scratch with the DOM-API in PHP. Maybe creating a new extension to avoid problems with all the people using domxml already (and therefore not relying on keeping the old API). Ideas, thoughts, etc? i'd rather see an effort of finally getting domxml itself into a mature state. it's about time, imho. regarding the api, it's not that people could/should have relied upon a stable domxml api. it's _still_ experimental and marked as such. i'm running a patched[1] version of domxml for quite some time for development to get the functionality i need(ed), too. let's whip this beast into shape. [1] for patches see http://www.azzit.de/patches/php4/ regards, -lukas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Extra EXIF headers (exif.c)
Hello there. I have been investigating the EXIF tags that Windows XP can add to files,
and have successfully identified five extra tags and their mappings to the fields on
the File|Properties...|Summary tab in Explorer (both simple and advanced views).
XP ignores the standard UserComment field, alas, so I was forced to look into this.
(For those not using XP to manage their photos, Explorer allows you to view most EXIF
data within the File|Properties... dialog, and even add some EXIF fields as columns in
Detail view)
Since I don't have CVS access, or even a PHP development environment that would allow
me to do the necessary changes myself, I am posting this here in hope that someone
will add this to the upcoming 4.2.0 build.
I suggest the following entries for the TagTable:
static const struct {
unsigned short Tag;
char *Desc;
} TagTable[] = {
{ 0x00FE, NewSubFile},
{ 0x00FF, SubFile},
..
{ 0x9c9b, Title }, // Win XP specific, Unicode
{ 0x9c9c, Comments }, // Win XP specific, Unicode
{ 0x9c9d, Author },// Win XP specific, Unicode
{ 0x9c9e, Keywords }, // Win XP specific, Unicode
{ 0x9c9f, Subject }, // Win XP specific, Unicode, not to be confused with
SubjectDistance and SubjectLocation
Best regards,
Rui Carmo
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re[3]: [PHP-DEV] Let's fork GD!
Hi, If you think that imagemagick is great, so don't you write an extention for it yourself. Other developers can deside on buildtime which image library they use. Here are some additionals arguments: http://www.menalto.com/projects/gallery/modules.php?op=modloadname=GalleryFAQfile=indexmyfaq=yesid_cat=3categories=3+-+Gallery+Graphics+Toolkitsparent_id=0 -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extra EXIF headers (exif.c)
Sounds nice but it will be a lot more work :-)
I will try to include them and verify it. But we are in RC3 so you will
find the
code not before 4.3.
marcus
At 14:42 13.04.2002, you wrote:
Hello there. I have been investigating the EXIF tags that Windows XP can
add to files, and have successfully identified five extra tags and their
mappings to the fields on the File|Properties...|Summary tab in Explorer
(both simple and advanced views). XP ignores the standard UserComment
field, alas, so I was forced to look into this.
(For those not using XP to manage their photos, Explorer allows you to
view most EXIF data within the File|Properties... dialog, and even add
some EXIF fields as columns in Detail view)
Since I don't have CVS access, or even a PHP development environment that
would allow me to do the necessary changes myself, I am posting this here
in hope that someone will add this to the upcoming 4.2.0 build.
I suggest the following entries for the TagTable:
static const struct {
unsigned short Tag;
char *Desc;
} TagTable[] = {
{ 0x00FE, NewSubFile},
{ 0x00FF, SubFile},
..
{ 0x9c9b, Title }, // Win XP specific, Unicode
{ 0x9c9c, Comments }, // Win XP specific, Unicode
{ 0x9c9d, Author },// Win XP specific, Unicode
{ 0x9c9e, Keywords }, // Win XP specific, Unicode
{ 0x9c9f, Subject }, // Win XP specific, Unicode, not to be confused
with SubjectDistance and SubjectLocation
Best regards,
Rui Carmo
--
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[3]: [PHP-DEV] Let's fork GD!
I have, and so have all sorts of other people. Look at packages like jpgraph. GD does enough. It is a clean and simple library. The ImageMagick library is full of buffer overruns and crash bugs. Try drawing a big circle, for example. The thing writes all over memory it isn't supposed to. If it ever matures, or preferably gets a complete rewrite, I would consider it. -Rasmus On Sat, 13 Apr 2002, Daniel Lorch wrote: Hi, why not replace GD by imagemagick which is better anyway? Have you looked under the skirts of ImageMagick? It is one of the poorest-written libraries I have seen. Have you ever tried to do something productive with GD? It is one of the poorest tools I have ever seen. Seriously: imagemagick can do *ALOT* more than GD. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] setlocale
Hi, I checked the HTTP1.1 protocol and it says: 3.10 Language Tags A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content- Language fields. The syntax and registry of HTTP language tags is the same as that defined by RFC 1766 [1]. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags: language-tag = primary-tag *( - subtag ) primary-tag = 1*8ALPHA subtag= 1*8ALPHA The definition of ALPHA is: UPALPHA= any US-ASCII uppercase letter A..Z LOALPHA= any US-ASCII lowercase letter a..z ALPHA = UPALPHA | LOALPHA White space is not allowed within the tag and all tags are case- insensitive. The name space of language tags is administered by the IANA. Example tags include: en, en-US, en-cockney, i-cherokee, x-pig-latin where any two-letter primary-tag is an ISO-639 language abbreviation and any two-letter initial subtag is an ISO-3166 country code. (The last three tags above are not registered tags; all but the last are examples of tags which could be registered in future.) From some Linux manual: A locale name is typically of the form language[_territory][.codeset][@modifier], where language is an ISO 639 language code, territory is an ISO 3166 country code, and codeset is a character set or encoding identifier like ISO-8859-1 or UTF-8. So this is VERY confusing, because the HTTP protocol says that en-us or en-US is allowed, but most of the setlocale implementations only understand en_US (note the underbar). Therefore there are three ways we can fix this: 1) Ignore it and let users convert what is sent by the browser to something that their setlocale understands. 2) Force the php setlocale procedure to convert everything to the language_COUNTRY format before passing it to setlocale. 3) Modify configure.in so it calls setlocale to find out what is understood by the machine it's running on, then have the php setlocale code convert as appropriately. Any comment? Fab. Original Message - From: Markus Fischer [EMAIL PROTECTED] To: fabwash [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, April 13, 2002 12:16 AM Subject: Re: [PHP-DEV] setlocale Interesting, I noticed this too. I would favour first to check why Microsoft uses a '-' instead of '_' and if the mapping to the locales really is always the same except the '-'. - Markus ps: I don't think this sort of check/hack belongs into PHP; not without further investigation at least. On Sat, Apr 13, 2002 at 12:04:55AM -0400, fabwash wrote : Hi all, my browser (IE6) sends en-us in the HTTP_ACCEPT_LANGUAGE instead of the usual en_US. Would it be a good idea to modify setlocale (in ext/standard/string.c) so that it upshifts what is after the - before calling the local setlocale, or do you think that should be done by the user? Fab. -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Mind if I MFH ? What QA did you do on it? the usual? ah... none :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extra EXIF headers (exif.c)
At 16:02 13.04.2002, you wrote: On Sat, Apr 13, 2002 at 03:25:30PM +0200, Marcus Börger wrote: Sounds nice but it will be a lot more work :-) I will try to include them and verify it. But we are in RC3 so you will find the code not before 4.3. OK, thanks! :) Maybe someone will build a Win32 version from CVS in the meantime, or I'll just put in the hours and see if I can build a Cygwin version of the extension. (Apache 1.3.24 is now packaged and compiled natively under Cygwin, so I've been wondering if the PHP distro would compile cleanly under it... :)) Best regards, Rui Carmo Question: what images did you work with jpeg or tiff? I cannot set the fields with my XP ? Perhaps you can send me one of your pictures with the fields set - 1 * 1 pixel would do! Filling in the names of the fields would be the easiest way for me. And keep replying to php-dev also. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extra EXIF headers (exif.c)
OK. I'm attaching a small (120x90) image I tagged. Just right-click on the image, select Properties and look at the Summary tab. When you apply changes, it saves the file and rewrites the headers. I have tested this on JPEG images from a Sony digital camera, and have dumped the file by hand to verify the tag location (XP inserts the tags after the standard camera header). Since my original message, I have also confirmed the tags using Photo Studio (http://www.stuffware.co.uk/) :) I apologise for not CCing php-dev before, since I am not actually subscribed to the list. :) Best regards, Rui Carmo On Sat, Apr 13, 2002 at 04:14:44PM +0200, Marcus Börger wrote: At 16:02 13.04.2002, you wrote: On Sat, Apr 13, 2002 at 03:25:30PM +0200, Marcus Börger wrote: Sounds nice but it will be a lot more work :-) I will try to include them and verify it. But we are in RC3 so you will find the code not before 4.3. OK, thanks! :) Maybe someone will build a Win32 version from CVS in the meantime, or I'll just put in the hours and see if I can build a Cygwin version of the extension. (Apache 1.3.24 is now packaged and compiled natively under Cygwin, so I've been wondering if the PHP distro would compile cleanly under it... :)) Best regards, Rui Carmo Question: what images did you work with jpeg or tiff? I cannot set the fields with my XP ? Perhaps you can send me one of your pictures with the fields set - 1 * 1 pixel would do! Filling in the names of the fields would be the easiest way for me. And keep replying to php-dev also. marcus attachment: DSC01660_sm.JPG -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
* Daniel Lorch wrote: If GD was so great, why do products like typo3 and gallery rather use imagemagick? Maybe because it's more feature-rich, supports 68 formats and can do ALOT of effects? Yep, but I don't see a reason why GD should be thrown away. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone wrote persistent variable extension?
You've posted on this a couple of times. The thing with srm is that they're set up as 'remote' functions. In order to get to a function, to have to contact a (net necessarily) remote daemon. While I do agree that this is cool and useful functionality, what I'm looking for is something that IMHO is a bit simpler. Let me explain: Let's say that for a given web application I have a function library in a file 'functions.php'. Every page in the site includes this file... I've even put it in the prepend, so I don't have to remember to do it to every page. By doing this, all of the desired functions 'magically appear' for my other scripts to execute. Keeping the include option would allow for caching of these files, using on of the available cache extensions (APC, Zend Cache) which would produce a similar effect. What I'm proposing (for the functions anywats) is that a list of files that exists in the PHP.ini file get loaded. The functions from these files stay resident in memory and get merged with the local function table prior to script execution. In a way, it would function like extensions written in PHP as opposed to C. This functionality would also exist for class definitions using the same mechanism. For variables, I was thinking about a 'registration' process, similar to how session variables are registered. This registration would not set the variables to memory, as it does for sessions, you would need to call a specific function for that. In this way, every process could get a 'base' data set to work with. Prior to script execution, these variables can be loaded / copied into the global scope. Alternately, you can retreive them through a function ( $data = perDataGet($key) ) I hope this makes things more clear. The SEM stuff looks really cool, I just don't think it fits the needs that I have. We could, however, discuss further I may be wrong. Medvitz [EMAIL PROTECTED] wrote: Hello, On Fri, 12 Apr 2002, medvitz wrote: I'm currently looking into an extension that would allow both persistent variables, as well as persistent functions. At this point I'm still going through the internals to determine the feasibility of such an extension. I dont want to plug, but SRM can already do this: http://www.vl-srm.net/doc/features.remote-functions.php The documentation still need to be written, but that will follow soon. Derick --- Did I help you? Consider a gift: http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone wrote persistent variable extension?
What I'm proposing (for the functions anywats) is that a list of files that exists in the PHP.ini file get loaded. The functions from these files stay resident in memory and get merged with the local function table prior to script execution. In a way, it would function like extensions written in PHP as opposed to C. This functionality would also exist for class definitions using the same mechanism. How is this different from using an auto-prepend? -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Let's fork GD!
Daniel, it's all nice and good but there's no production version of ext/imagick available. Until this isn't done, everything else is waste of time ;) - Markus On Sat, Apr 13, 2002 at 03:04:51PM +0200, Daniel Lorch wrote : Hi, If you think that imagemagick is great, so don't you write an extention for it yourself. Other developers can deside on buildtime which image library they use. I posted this link already before. An (experimental) interface already exists (done by chregu): http://pear.php.net/manual/en/pecl.imagick.php I am asking to make imagemagick a native extension to PHP, which is primarily an documentation issue. If someone searches for image functions in the manual not the GD library, but imagemagick should appear. http://www.php.net/manual/en/ref.image.php If GD was so great, why do products like typo3 and gallery rather use imagemagick? Maybe because it's more feature-rich, supports 68 formats and can do ALOT of effects? http://www.typo3.com/Server_software_and.1051.1.html http://www.menalto.com/projects/gallery/modules.php?op=modloadname=Newsfile=index Did you have a look at imagemagicks feature list? Isn't it exactly what people would like to do? --- Here are just a few examples of what ImageMagick can do: - Convert an image from one format to another (e.g. TIFF to JPEG) - Resize, rotate, sharpen, color reduce, or add special effects to an image - Create a montage of image thumbnails - Create a transparent image suitable for use on the Web - Turn a group of images into a GIF animation sequence - Create a composite image by combining several separate images - Draw shapes or text on an image - Decorate an image with a border or frame - Describe the format and characteristics of an image - .. http://www.imagemagick.org --- -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Mind if I MFH ? What QA did you do on it? the usual? ah... none :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone wrote persistent variable extension?
This may be relevant to the discussion: http://pwee.sourceforge.net On Saturday, April 13, 2002, at 11:29 AM, medvitz wrote: You've posted on this a couple of times. The thing with srm is that they're set up as 'remote' functions. In order to get to a function, to have to contact a (net necessarily) remote daemon. While I do agree that this is cool and useful functionality, what I'm looking for is something that IMHO is a bit simpler. Let me explain: Let's say that for a given web application I have a function library in a file 'functions.php'. Every page in the site includes this file... I've even put it in the prepend, so I don't have to remember to do it to every page. By doing this, all of the desired functions 'magically appear' for my other scripts to execute. Keeping the include option would allow for caching of these files, using on of the available cache extensions (APC, Zend Cache) which would produce a similar effect. What I'm proposing (for the functions anywats) is that a list of files that exists in the PHP.ini file get loaded. The functions from these files stay resident in memory and get merged with the local function table prior to script execution. In a way, it would function like extensions written in PHP as opposed to C. This functionality would also exist for class definitions using the same mechanism. For variables, I was thinking about a 'registration' process, similar to how session variables are registered. This registration would not set the variables to memory, as it does for sessions, you would need to call a specific function for that. In this way, every process could get a 'base' data set to work with. Prior to script execution, these variables can be loaded / copied into the global scope. Alternately, you can retreive them through a function ( $data = perDataGet($key) ) I hope this makes things more clear. The SEM stuff looks really cool, I just don't think it fits the needs that I have. We could, however, discuss further I may be wrong. Medvitz [EMAIL PROTECTED] wrote: Hello, On Fri, 12 Apr 2002, medvitz wrote: I'm currently looking into an extension that would allow both persistent variables, as well as persistent functions. At this point I'm still going through the internals to determine the feasibility of such an extension. I dont want to plug, but SRM can already do this: http://www.vl-srm.net/doc/features.remote-functions.php The documentation still need to be written, but that will follow soon. Derick --- Did I help you? Consider a gift: http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php // George Schlossnagle // Principal Consultant // OmniTI, Inc http://www.omniti.com // (c) 301.343.6422 (e) [EMAIL PROTECTED] // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/exif exif.c
Maybe you didn't tested ZTS mode?
On Sat, Apr 13, 2002 at 02:39:36AM +0200, Marcus Börger wrote :
Sure i do and it worked fine for all tests!?
marcus
At 00:02 13.04.2002, you wrote:
sniper Fri Apr 12 18:02:30 2002 EDT
Modified files:
/php4/ext/exif exif.c
Log:
Fix the build.
# Marcus, do you TEST build at all before you commit?!
Index: php4/ext/exif/exif.c
diff -u php4/ext/exif/exif.c:1.89 php4/ext/exif/exif.c:1.90
--- php4/ext/exif/exif.c:1.89 Fri Apr 12 12:35:56 2002
+++ php4/ext/exif/exif.cFri Apr 12 18:02:28 2002
-17,7 +17,7
+--+
*/
-/* $Id: exif.c,v 1.89 2002/04/12 16:35:56 helly Exp $ */
+/* $Id: exif.c,v 1.90 2002/04/12 22:02:28 sniper Exp $ */
/* ToDos
*
-107,9 +107,7
};
/* }}} */
-#define EXIF_VERSION 1.3 $Id: exif.c,v 1.89 2002/04/12 16:35:56 helly
Exp $
-
-ZEND_DECLARE_MODULE_GLOBALS(exif)
+#define EXIF_VERSION 1.3 $Id: exif.c,v 1.90 2002/04/12 22:02:28 sniper
Exp $
/* {{{ PHP_MINFO_FUNCTION
*/
-132,6 +130,8
char * decode_jis_be;
char * decode_jis_le;
ZEND_END_MODULE_GLOBALS(exif)
+
+ZEND_DECLARE_MODULE_GLOBALS(exif)
#ifdef ZTS
#define EXIF_G(v) TSRMG(exif_globals_id, zend_exif_globals *, v)
--
PHP CVS 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
--
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Mind if I MFH ? What QA did you do on it? the usual? ah... none :)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re[3]: [PHP-DEV] Let's fork GD!
+1 -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 13, 2002 7:48 AM To: Daniel Lorch Cc: [EMAIL PROTECTED] Subject: Re[3]: [PHP-DEV] Let's fork GD! I have, and so have all sorts of other people. Look at packages like jpgraph. GD does enough. It is a clean and simple library. The ImageMagick library is full of buffer overruns and crash bugs. Try drawing a big circle, for example. The thing writes all over memory it isn't supposed to. If it ever matures, or preferably gets a complete rewrite, I would consider it. -Rasmus On Sat, 13 Apr 2002, Daniel Lorch wrote: Hi, why not replace GD by imagemagick which is better anyway? Have you looked under the skirts of ImageMagick? It is one of the poorest-written libraries I have seen. Have you ever tried to do something productive with GD? It is one of the poorest tools I have ever seen. Seriously: imagemagick can do *ALOT* more than GD. -daniel -- 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] The PHP Platform
I don't really have an issue with the Zend people making money from their products. The concern I have is that they sell perfoamance enhancing products. Because they are selling these, I worry that performance in the base Zend engine will not be / is not a primary concern. I think that performance should be a top priority for the 'base' engine. People outside of Zend are contributing a good amount of time to creating extensions, writing PEAR modules, and promoting PHP, and , in my opinion , these efforts are being used by Zend who are holding back on performance. Yes... the optimizer is free. But it doesn't always have to be. I like PHP, I use PHP, I use PHP for clients work, so yes I make money off of PHP. I expect that the Zend psople can as well, without holding back on the community that helped them get where they are today. I've got some biases here. I was a subscriber, for a time to the developer's pachage that they had towards the beginning. For $600 a year I got the Encoder, the debug server and 2 client licenses. They had a pay by month option and I selected this, as my company wasn't going to reimburse me for this expense. When my bank got bought and I had to get use a new card to keep up on the payments no one could do it. I emailed the people who handled the credit card transactiosn, and I emailed Zend. I got no responsse what-so-ever, but a lot of emails telling me they couldn't bill my card (all of which I replied to asking how to change my card info). I'm glad you have had good expeirience with them, 'cause I haven't. And the package that made the mose sense to me, they no longer offer. Medvitz Dave Mertens wrote: On Fri, Apr 12, 2002 at 07:32:47PM -0400, medvitz wrote: The issue I have with PHP is that the people in charge have reasons for not implementing performance enhancements in the base code. They charge a fair amount for add-ons that increases performance drastically. I could actually argue that extensibility and performance on the back end aren't what they should be for this reason. Not that I want to make enemies here, but I think this is a realistic criticism. Not to mention that the Qt license that is used prevents anyone from making extensions and selling them w/o an additional license from the Zend people. So they are able to make money off of the hard work of all of the module contributors, which I think really blows. So if i understand what your saying you don't like that fact the Zend had write an (very) good engine for PHP4 and now is making some money with it?? Don't forget Zend is a commercial company that is doing a lot for the open source community. Without them you didn't had PHP4! Without all the Zend optimalisations (but with the free Zend Optimzer (You've installed it, right?!)) PHP4 has a good performance. With the money they make with their products like Zend Encoder, Zend Cache, etc they can continue developing on the Zend Engine. They don't force you to but their products. They only say that they can really speed up your code. Companies where i work (a official gold microsoft partner ;-( ) has also bought the Zend products. My boss thinks the Zend products are very cheap in comparisment with Microsoft products. Microsoft is doing the same thing. They provide you with a 'free' IIS webserver, but they have also products that enhance IIS like Commerce Server, Content Server, etc. The fact that a commercial company like Zend is working on PHP is for a large number of companies very important. Most open-source projects don't have a proper helpdesk. Zend is providing a very good helpdesk. But all this have two sides. While we (PHP developers) build upon PHP4, and make money with the applications we write with it. And Zend is making money with other Zend products and they make sure PHP is good enough for companies. So don't trap Zend into the ground. Because of them you can program OOP in PHP! That all from me.. Dave Mertens -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Uploading new release
I've been trying to upload a new version of the Log package, but I keep running into the same problem. I'll be able to upload the new package, but after a verify it, it redirects me back to the login authentication page and asks me to re-enter my username and password. I can't seem to break this loop, so the release is never successfully uploaded. Is this a site bug, or am I doing something wrong? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Uploading new release
Apologies; I sent this to the wrong list. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] Let's fork GD!
Hi, it's all nice and good but there's no production version of ext/imagick available. Until this isn't done, everything else is waste of time ;) - Markus I didn't know imagemagick's sources were of *THAT* bad quality. Rasmus' arguments convinced me not to move to imagemagick (yet). P.S.: It's about imagemagick's *ITSELF*, not about ext/imagemagick which has bad quality. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] domxml nightmare and suggestion
Actually, I'd rather see a w3c DOM compliant module than a makeshift DOM, which is what DOMXML seems to be. This would make a lot of things a lot easier, not to mention standard Medvitz Lukas Schroeder wrote: On Sat, Apr 13, 2002 at 12:41:44PM +0200, Christian Stocker wrote: top issues... Personally I don't have much problems with this extension, but missing docu and the API as a moving target, is something which worries a lot of people. But one of the weakest things about domxml is IMHO that it promises a DOM-API, which it does not provide very consitently and a lot of functionality is still missing. With all this points, i'd like to start a discussion about starting from scratch with the DOM-API in PHP. Maybe creating a new extension to avoid problems with all the people using domxml already (and therefore not relying on keeping the old API). Ideas, thoughts, etc? i'd rather see an effort of finally getting domxml itself into a mature state. it's about time, imho. regarding the api, it's not that people could/should have relied upon a stable domxml api. it's _still_ experimental and marked as such. i'm running a patched[1] version of domxml for quite some time for development to get the functionality i need(ed), too. let's whip this beast into shape. [1] for patches see http://www.azzit.de/patches/php4/ regards, -lukas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] C++ Class Wrapping
Is there a way to wrap existing c++ classes into a PHP class (via an extension) ? Medvitz -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The PHP Platform
On Sat, Apr 13, 2002 at 11:57:13AM -0400, medvitz wrote: The concern I have is that they sell perfoamance enhancing products. Because they are selling these, I worry that performance in the base Zend engine will not be / is not a primary concern. I think that performance should be a top priority for the 'base' engine. People outside of Zend are contributing a good amount of time to creating extensions, writing PEAR modules, and promoting PHP, and , in my opinion , these efforts are being used by Zend who are holding back on performance. Yes... the optimizer is free. But it doesn't always have to be. I like PHP, I use PHP, I use PHP for clients work, so yes I make money off of PHP. I expect that the Zend psople can as well, without holding back on the community that helped them get where they are today. Even PHP3 has a Zend engine (0.5). Most developers these days started with Version 3. PHP2/FI wasn't mature enough for companies. For companies where i work for it's very important that there's a company behind PHP like Zend. Zend is now writing ZE2. They continueing the work they all doing for years now. Further the API of the Zend Engine is open. So everybody could write a program/library like Zend Accelerator. The only problem is that the products of Zend have a very low price in comparisment to other development platforms. Writing them yourself would costs you more. I even think that without Zend there wasn't PHP anymore because they're not only writing the heart of PHP, they also sets the goals for PHP. At that part is very important of companies. And they're not forcing you to buy their products. But most companies do, because it improves the engine. And maybe if Zend is making enough money with PHP that can actually really promote PHP as a mature language like Microsoft and Sun are doing. But i don't want to critismize you. I understand you completely. Because for my own site i can't eforth the Zend encoder and Accelerator. And than i wish that those products where for free. But noting is this world comes for free. Not even open-source products. Oh yes, the products are free. As far as i know there arent programs for PHP like there are for ASP/JAVA. Brainbench was offering some certificates for PHP4 developers. What i'm trying so say is simple. PHP needs a 'commercial' boost and Zend is providing it. Because like is said in other threads, PHP is now mainlt a tool for dynamic webpages. But these days customers want web applications like CMS systems and integrated back-ends with other companies and not only a homepage with some dynamic features like a guest book. All major benefits that PHP had on Microsoft ASP is now gone with .NET C# and VB are providing the same functionality as PHP is. I really have to fight within the company i work to keep PHP. Do you know what PHP really needs? Good native XML and SOAP support.. Without that it's very hard to convince my boss that PHP is the right tool for the job. I develop for a living. And i'm not only programming in PHP. I do also Java, VB, C# and a little C. And i have to say that even with the high license costs of Microsoft, they are providing a solid developer base with good support from MSDN and Technet. You can't around it and that is why my boss want to use .NET. Ever saw an ad for PHP?? You don't read of PHP. If you're not following the PHP mailingslists you know shit.. I've got some biases here. I was a subscriber, for a time to the developer's pachage that they had towards the beginning. For $600 a year I got the Encoder, the debug server and 2 client licenses. They had a pay by month option and I selected this, as my company wasn't going to reimburse me for this expense. When my bank got bought and I had to get use a new card to keep up on the payments no one could do it. I emailed the people who handled the credit card transactiosn, and I emailed Zend. I got no responsse what-so-ever, but a lot of emails telling me they couldn't bill my card (all of which I replied to asking how to change my card info). I'm glad you have had good expeirience with them, 'cause I haven't. And the package that made the mose sense to me, they no longer offer. I don't do payments for my company. I'm not allowed to do that ;-( But i have a boss that really have an open mind. He tries several things. And because i said that i wanted the Zend accelerator because it's speed up the web application he bought it immediatly. But we build PHP sites without the Zend tools. The Zend tools are only installed on the production server. That way we're forced to write efficiant code. And because our developing enviroment is quick (we use single Pentium 3 500 processor with 128 MB of ram and IDE harddisk, normal desktops thus..) the productions sites are really flying. And i'm really sorry that Zend let you down with your creditcard payment. Dave Mertens P.S. sorry for my bad
Re: [PHP-DEV] C++ Class Wrapping
Hi, Is there a way to wrap existing c++ classes into a PHP class (via an extension) ? This usually happens by writing an extension for PHP, although C is the common language to do this: http://www.php.net/manual/en/zend.php -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C++ Class Wrapping
Can you use C++ however? I'm very interested in writing/using a standard w3c binding for DOM XML - Original Message - From: Daniel Lorch [EMAIL PROTECTED] To: medvitz [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, April 13, 2002 7:08 PM Subject: Re: [PHP-DEV] C++ Class Wrapping Hi, Is there a way to wrap existing c++ classes into a PHP class (via an extension) ? This usually happens by writing an extension for PHP, although C is the common language to do this: http://www.php.net/manual/en/zend.php -daniel -- 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] C++ Class Wrapping
Can you use C++ however? I'm very interested in writing/using a standard w3c binding for DOM XML - Original Message - From: Daniel Lorch [EMAIL PROTECTED] To: medvitz [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, April 13, 2002 7:08 PM Subject: Re: [PHP-DEV] C++ Class Wrapping Hi, Is there a way to wrap existing c++ classes into a PHP class (via an extension) ? This usually happens by writing an extension for PHP, although C is the common language to do this: http://www.php.net/manual/en/zend.php -daniel -- 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] domxml nightmare and suggestion
On Sat, 13 Apr 2002, medvitz wrote: Actually, I'd rather see a w3c DOM compliant module than a makeshift DOM, which is what DOMXML seems to be. This would make a lot of things a lot easier, not to mention standard Then fix the DomXML extension we have now, but also think about Backward Compability. The last thing we're waiting for is yet another extension with another API. Derick Medvitz Lukas Schroeder wrote: On Sat, Apr 13, 2002 at 12:41:44PM +0200, Christian Stocker wrote: top issues... Personally I don't have much problems with this extension, but missing docu and the API as a moving target, is something which worries a lot of people. But one of the weakest things about domxml is IMHO that it promises a DOM-API, which it does not provide very consitently and a lot of functionality is still missing. With all this points, i'd like to start a discussion about starting from scratch with the DOM-API in PHP. Maybe creating a new extension to avoid problems with all the people using domxml already (and therefore not relying on keeping the old API). Ideas, thoughts, etc? i'd rather see an effort of finally getting domxml itself into a mature state. it's about time, imho. regarding the api, it's not that people could/should have relied upon a stable domxml api. it's _still_ experimental and marked as such. i'm running a patched[1] version of domxml for quite some time for development to get the functionality i need(ed), too. let's whip this beast into shape. [1] for patches see http://www.azzit.de/patches/php4/ regards, -lukas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Did I help you? Consider a gift: http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] domxml nightmare and suggestion
We would still have the 'dom_*()' namespace if someone wants to do a clean implementation from scratch. On Sun, Apr 14, 2002 at 02:11:49AM +0200, [EMAIL PROTECTED] wrote : On Sat, 13 Apr 2002, medvitz wrote: Actually, I'd rather see a w3c DOM compliant module than a makeshift DOM, which is what DOMXML seems to be. This would make a lot of things a lot easier, not to mention standard Then fix the DomXML extension we have now, but also think about Backward Compability. The last thing we're waiting for is yet another extension with another API. Derick Medvitz Lukas Schroeder wrote: On Sat, Apr 13, 2002 at 12:41:44PM +0200, Christian Stocker wrote: top issues... Personally I don't have much problems with this extension, but missing docu and the API as a moving target, is something which worries a lot of people. But one of the weakest things about domxml is IMHO that it promises a DOM-API, which it does not provide very consitently and a lot of functionality is still missing. With all this points, i'd like to start a discussion about starting from scratch with the DOM-API in PHP. Maybe creating a new extension to avoid problems with all the people using domxml already (and therefore not relying on keeping the old API). Ideas, thoughts, etc? i'd rather see an effort of finally getting domxml itself into a mature state. it's about time, imho. regarding the api, it's not that people could/should have relied upon a stable domxml api. it's _still_ experimental and marked as such. i'm running a patched[1] version of domxml for quite some time for development to get the functionality i need(ed), too. let's whip this beast into shape. [1] for patches see http://www.azzit.de/patches/php4/ regards, -lukas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Did I help you? Consider a gift: http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Mind if I MFH ? What QA did you do on it? the usual? ah... none :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] domxml nightmare and suggestion
I would like to do this if I have the time. As mentioned, i'm working on a project that needs the latest version of PHP. If I could participate in this to make it happen much sooner, I'd be happy to. - Original Message - From: [EMAIL PROTECTED] To: medvitz [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, April 13, 2002 8:11 PM Subject: Re: [PHP-DEV] domxml nightmare and suggestion On Sat, 13 Apr 2002, medvitz wrote: Actually, I'd rather see a w3c DOM compliant module than a makeshift DOM, which is what DOMXML seems to be. This would make a lot of things a lot easier, not to mention standard Then fix the DomXML extension we have now, but also think about Backward Compability. The last thing we're waiting for is yet another extension with another API. Derick Medvitz Lukas Schroeder wrote: On Sat, Apr 13, 2002 at 12:41:44PM +0200, Christian Stocker wrote: top issues... Personally I don't have much problems with this extension, but missing docu and the API as a moving target, is something which worries a lot of people. But one of the weakest things about domxml is IMHO that it promises a DOM-API, which it does not provide very consitently and a lot of functionality is still missing. With all this points, i'd like to start a discussion about starting from scratch with the DOM-API in PHP. Maybe creating a new extension to avoid problems with all the people using domxml already (and therefore not relying on keeping the old API). Ideas, thoughts, etc? i'd rather see an effort of finally getting domxml itself into a mature state. it's about time, imho. regarding the api, it's not that people could/should have relied upon a stable domxml api. it's _still_ experimental and marked as such. i'm running a patched[1] version of domxml for quite some time for development to get the functionality i need(ed), too. let's whip this beast into shape. [1] for patches see http://www.azzit.de/patches/php4/ regards, -lukas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Did I help you? Consider a gift: http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- 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-DEV] Copyright question
Hello, I have a php extension and I was working on a website. I copyied/stole the layout/code from qa.php.net. The extension is opensource and leaves the copyright (Copyright © 1997 - 2002 PHP Group All rights reserved.) on the site. Can I do this or does this break the liscence? I like the layout and i think php users/developers are useto the layout of the php site thats why i want to be consitistant. - Brad __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Copyright question
Hi, I like the layout and i think php users/developers are useto the layout of the php site thats why i want to be consitistant. I asked the same thing some time ago. It turned out to be ok: http://news.php.net/article.php?group=php.mirrorsarticle=8320 http://news.php.net/article.php?group=php.mirrorsarticle=8332 http://news.php.net/article.php?group=php.mirrorsarticle=8333 This is how it looks: http://daniel.lorch.cc/projects/disk_usage/ Either I'm blind or I still couldn't find out how to subscribe to PHP-mirrors .. Any hints? -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T1lib thread safety
Should we print a warning at the end of configure listing what libraries you are trying to link with that we know are not thread safe? - Stig On Sat, 2002-04-13 at 07:00, Rasmus Lerdorf wrote: Just the tip of the iceberg. There are a bunch of libraries that PHP can talk to that are not threadsafe. It's going to take a while before Apache2+PHP is going to be useful. For GD specifically, yes we can put in some mutexes as I earlier today put a copy of the GD library into PHP CVS so we can fiddle with it and distribute our own modified GD with PHP. -Rasmus On Sat, 13 Apr 2002, Brian Havard wrote: While doing some testing with Apache 2.0.35+PHP4.2.0RC3 I'm getting random crashes in T1_LoadFont(). Looking through the t1lib source (v1.3.1) I see frequent use of global variables which suggests it isn't thread safe. Is this a known problem? Maybe some mutexes in GD would help -- 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] C++ Class Wrapping
Sure you can. Take a look at for example ext/dotnet/dotnet.cpp. - Stig On Sun, 2002-04-14 at 02:02, Ken Egervari wrote: Can you use C++ however? I'm very interested in writing/using a standard w3c binding for DOM XML - Original Message - From: Daniel Lorch [EMAIL PROTECTED] To: medvitz [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, April 13, 2002 7:08 PM Subject: Re: [PHP-DEV] C++ Class Wrapping Hi, Is there a way to wrap existing c++ classes into a PHP class (via an extension) ? This usually happens by writing an extension for PHP, although C is the common language to do this: http://www.php.net/manual/en/zend.php -daniel -- 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
