Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt

Marcus Börger wrote: At 20:20 12.03.2003, Andrei Zmievski wrote: On Wed, 12 Mar 2003, Marcus Börger wrote: > This works even though i do not like extends FOO. Why? Both C# and Java (AFAIR) allow interfaces to extend other interfaces. Because of the second part of the answer. It is a little bit

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt

Andrei Zmievski wrote: On Wed, 12 Mar 2003, Sebastian Bergmann wrote: I have seen extended interfaces quite often in the Java world. IIRC, the following code currently runs without problems and it should stay that way, if it does not harm us in any way: I wasn't talking about interfaces

Re: [PHP-DEV] Moderate PHP-DEV

Sascha Schumann wrote: Aside from renaming the php-dev list, we should remove the 'PHP and Zend [snip] Sounds good. Then another item that might be considered if it is not already done, allowing posts only from those that have cvs access. A second conditional list of allowed posters can be

Re: [PHP-DEV] Moderate PHP-DEV

Sascha Schumann wrote: if even that description doesn't work, then nothing would work, not even changing the name. Well, it is obvious that some folks don't read that description and simply move forward, because "php-dev" sounds about right. They are "PHP developers" and so a list ca

Re: [PHP-DEV] $GLOBALS broken?

Shane Caraveo wrote: It's a patch to ze2 Actually, it may not have been to ze2 itself. that was done over the weekend, there is a new ini setting that if you turn it on will fix the problem, just cannot remember what it was right now... Shane Sebastian Bergmann wrote: Notice: Unde

Re: [PHP-DEV] $GLOBALS broken?

It's a patch to ze2 that was done over the weekend, there is a new ini setting that if you turn it on will fix the problem, just cannot remember what it was right now... Shane Sebastian Bergmann wrote: Notice: Undefined variable: GLOBALS in E:\test.php on line 7 1 -- PHP Development Ma

Re: [PHP-DEV] magic_quotes on the environment?

Rasmus Lerdorf wrote: I'm not convinced that escaping environment data is the correct thing to do in the first place, and I would like to change php to not escape env vars if magic_quotes_gpc is on. Any opinions on this? This changed somewhere along the line then. Originally magic quotes only

[PHP-DEV] magic_quotes on the environment?

Even though magic_quotes_gpc is documented to addslashes to get/post/cookie, it also does it to the environment. This probably doesn't effect linux as much as windows, where all paths get escaped if magic_quotes_gpc is on. I find this rather anoying since I am trying to build environments for

Re: [PHP-DEV] Tie'ing variables

So I'm not clear on how I am should expect this to work. A simple script: error_reporting(2047); print_r($_ENV); is now completely broken unless you turn on register_long_arrays. If that is expected behaviour, register_long_arrays must be on by default. Shane Zeev Suraski wrote: I wanted to d

Re: [PHP-DEV] Piping to the PHP binary

4.3.1 works fine. Shane Dan Hardiker wrote: Hey all, echo "" | /path/to/php That works on php v4.2.x but Ive got 3 machines on v4.3.x and none of them seem to respond to the piping of the php config. v4.2.x Response

Re: [PHP-DEV] [WARNING] Release process for 4.3.2 starts RSN..

I wanted to run through all the cgi stuff in detail again for 432, but likely wont have the time by the 26th to do that. Shane Jani Taskinen wrote: To get this thing started, I'm going to roll PHP 4.3.2-pre1 on Wednesday, 26th Feb, around 3pm EEST. And I'll announce it on php-general

Re: [PHP-DEV] Performance degradation

Rasmus Lerdorf wrote: On Sun, 23 Feb 2003, Shane Caraveo wrote: CGI, right? Part of this may be from the path_info handling I've added. The extra realpath() and fstat() calls are not cgi specific, so if what you added only affects cgi, then that isn't the big problem. -Rasmus ok,

Re: [PHP-DEV] Performance degradation

Rasmus Lerdorf wrote: So, I am just starting out down the path to figure out why PHP 4.3 has gotten so much slower than 4.2. "strace -c" provides the first clue. A straight "./configure --enable-inline-optimization && make" command-line build for 4.2, 4.3 and 5.0 run on a simple hello world scrip

[PHP-DEV] proc_open() patch

The attached patch adds 2 optional parameters to proc_open(). The first, cwd, and the second is an array for executing with a custom environment. I've tested this on w2k and osx. Comments, fixes, changes, and testing on Linux, would be appreciated. Shane Index: ext/standard/proc_open.c =

Re: [PHP-DEV] [PATCH] sapi/nsapi/nsapi.c

Excelent, The CGI vars are correct. One less sapi module to deal with :) Shane Uwe Schindler wrote: The variables you explain are surely there. But a lot of scripts depend on other headers, which the client sent. The SAPI module only creates Variables for a subset of them (HTTP_USER_AGENT). Bu

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

Ilia A. wrote: I may be wrong since I haven't profiled this, but my understanding is that str_replace is much faster than doing either of the regex replacements. For that reason alone, there is a use for it. Normally it would be quite faster, however once case sensitivity is added to the mix I

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

Derick Rethans wrote: On Wed, 29 Jan 2003, Sara Golemon wrote: I've got an implementation put together, the patch for which can be viewed at: http://169.229.139.97/test/str_ireplace.diff.txt After some comments on IRC, here's an alternate version to the above patch. This second approach av

[PHP-DEV] INI_STR usage in browscap (and others) causes crash

Hello, We have several places in our code (specificly in browscap.c) where we have bugs due to either improper usage of INI_STR, or improper results from zend_ini.c:zend_ini_string. The code: if (INI_STR("browscap")) { zend_hash_destroy(&browser_hash); } Will fail if there is no 'brows

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

As a matter of fact I think it would be good idea to go for 4.3.1 in February because number of bugfixes in PHP_4_3 branch is already significant and since no major new features have been added there the QA process shouldn't take that long either. And I have a pretty bad bug I'm still trying

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

Ilia A. wrote: On January 15, 2003 10:27 am, Adam Wright wrote: Last ditch effort of "NotAPHPBug"? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not a

Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)

Roadmap: 1. Switch to ZE2 by default 2. Establish PECL CA authority and binary package/release process (particularly important for win32) 3. Bundle PHP-Soap (and stop the "bleeding of PHP users") 3a. Collect underpants 4. ? 5. Profit #3 doesn't belong in a general roadmap. What does

Re: [PHP-DEV] Bug # 21261 -- PHP_SELF not set correctly with sapi/CGI

Sara Golemon wrote: It looks like the correct behavior was broken with patch 1.199 to php/sapi/cgi/cgi_main.c Because there are a number of modifications in this patch and I don't want to go messing it up any further I'll ask the original patch submitter (shane) to take a look and reconsider the

Re: [PHP-DEV] [PATCH] CLI and CGI defaults

But --enable-cli is now a useless switch, because: * if you don't specify it, cli is built * if you specify it, cli is built * if you don't specify it, cli is not installed * if you specify it, cli is not installed Only --disable-cgi (--enable-cli still makes no difference) will install cli on

Re: [PHP-DEV] CGI and CLI (compromise proposal)

good for me. Shane Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php

Re: [PHP-DEV] CGI and CLI

Edin Kadribasic wrote: * On other platforms, the cgi *is* installed by 'make install' by default. To install cli something like, 'make install-cli', or 'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the second option would be more usefull for installing both, using both witho

Re: [PHP-DEV] CGI and CLI

No. At the most, if anything, CLI should output an error message: if(getenv("GATEWAY_INTERFACE") != NULL) { printf("This is the PHP CLI binary, please configure your server to use the correct PHP CGI binary."); exit(1); } Xavier Spriet wrote: Great. In that case, in order to make things a l

Re: [PHP-DEV] CGI and CLI

Andrei Zmievski wrote: On Wed, 18 Dec 2002, Andi Gutmans wrote: I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Derick and I hashed it out on IRC and we have a p

Re: [PHP-DEV] CGI and CLI

I would agree that this is a big problem. Shane Andrei Zmievski wrote: On Wed, 18 Dec 2002, Sascha Schumann wrote: The next point release after 4.2.0 was 4.2.1. There are too many major changes in 4.3 vs. 4.2 to call it a 'point release'. Semantics. Especially, there are stil

Re: [PHP-DEV] CGI and CLI

Plain and simple, and it is the ONLY way that 4.3 can be released. There is no way in hell I would support the release of PHP with the cli binary replacing the cgi binary. Change it back to the way it was in 4.2.x since there is no time to properly fix the problem. Leave it marked experimenta

Re: [PHP-DEV] CGI and CLI

Robin Thellend wrote: On Wed, 18 Dec 2002, Derick Rethans wrote: [...] I didn't say that it should be changed from php to php-cgi, as I do think that would be bad. Derick Why don't you just add a simple check in the CLI code to exec() the CGI binary if it is called as a CGI? if(getenv("GAT

Re: [PHP-DEV] php.exe - php-cgi.exe

3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I notic

Re: [PHP-DEV] php.exe - php-cgi.exe

Jani Taskinen wrote: On Mon, 9 Dec 2002, Shane Caraveo wrote: Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command

Re: [PHP-DEV] php.exe - php-cgi.exe

Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command line utils is a bad idea. marcus Well, fortunately I never

Re: [PHP-DEV] sapi/fastcgi

sapi/fastcgi should be deprecated. Sebastian Bergmann wrote: What happens to sapi/fastcgi, now that we have FastCGI support in sapi/cgi? IMHO, it should be removed for PHP 4.3.0 already. -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/un

Re: [PHP-DEV] Re: sapi/fastcgi

works fine for me without exiting, under mod_fastcgi on win32 and osx and my iis/fastcgi. There was a problem with exiting after each request on windows, but I fixed that a couple weeks ago. Shane Harald Radi wrote: i wasn't able to run it succesfully on windows. i can compile it and the binar

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /sapi/cgi cgi_main.c

Zeev Suraski wrote: > How does this patch possibly fix something in this magnitude? It > doesn't appear to do anything crucial at all, or do these variables have > some far-reaching indirect effect? > > Zeev Well, the one patch refered to in this thread was only a minor fix over the previous pat

[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /sapi/cgi cgi_main.c

but people familiar with CGI should review it carefully. Andi At 02:21 AM 12/2/2002 +, Shane Caraveo wrote: shane Sun Dec 1 21:21:01 2002 EDT Modified files: (Branch: PHP_4_3) /php4/sapi/cgi cgi_main.c Log: MFH Index: php4/sapi/cgi/cgi_main.c diff -u php4

Re: [PHP-DEV] Error during buildconf..

Jani Taskinen wrote: On Mon, 2 Dec 2002, Jani Taskinen wrote: I get this with PHP_4_3_0 branch (with Linux): /usr/bin/autoheader: Symbol `ssize_t' is not covered by /usr/share/autoconf/acconfig.h ./acconfig.h And main/php_config.h.in is not created. (this does not happen with HE

Re: [PHP-DEV] Error during buildconf..

Is this just starting? How long since your last configured? I just added two new m4 files, but they shouldn't get used unless you --enable-fastcgi, did you do that? Shane Magnus Määttä wrote: On Mon, 2 Dec 2002 04:39:34 +0200 (EET) Jani Taskinen <[EMAIL PROTECTED]> wrote: I get this with

[PHP-DEV] PHP 4.3 broken CGI behaviour

Hello, I just commited patches to fix CGI running under Apache. This also fixes issues with incorrect CGI environment variables that are received under ScriptAlias based CGI or mod_fastcgi. My previous email describing this is at http://marc.theaimsgroup.com/?l=php-dev&m=103834043816376&w=2

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

Is there any reason the ifdef __cplusplus doesn't work? There shouldn't be any need for extra processing or config options. J Smith wrote: How about adding something like this to skeleton.c: /* __begin_extern_c__ */ /* __end_extern_c__ */ And having the sed script in ext_skel replace them with

Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++

J Smith wrote: Attached is a patch to ext_skel that adds an optional argument (--cpp) that will create a PHP extension in C++ rather than C. Also attached is skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few modifications for using C++. I could've just made some changes t

Re: [PHP-DEV] C++ extensions and ext_skel

I think that would be quite cool, save me from having to do it manualy. Shane J Smith wrote: A couple of times a month, I get questions about from people looking to use C++ with PHP. Apparently, a lot of people end up reading some post I made to php.dev or something a year or so ago about C++,

[PHP-DEV] apache/cgi problems with path_info and discard-path

I ran into a problem with path_info using apache2/mod_fastcgi, so I configured apache to use php as regular cgi, and have the same exact problems. There are basicly two problems, first, --discard-path causes PHP to parse itself rather than the script, so I think discard-path is basicly a bad idea

Re: [PHP-DEV] Error Codes, Langs, etc

Sascha Schumann wrote: >cats or gettext comes to mind. Neither are usable, though, because PHP would need to support multiple concurrent message catalogues on a per-thread base. gettext/catgets associate exactly one language with each process through the use of environment varia

Re: [PHP-DEV] Error Codes, Langs, etc

John Coggeshall wrote: >I am definitely -1 for this idea. XML is a buzzword, it is >good in some cases >not so good in others, definitely not a one size fits all >solution. In PHP's >case it would add decency on an XML parser, make life of >developers adding, >modifying, removing error messages d

Re: [PHP-DEV] Error Codes, Langs, etc

I am completely +1 to the concept of taking error codes out of the PHP core and replacing them with an XML document, period. I had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using

Re: [PHP-DEV] Re: Windows Threads

Nick Loman wrote: Well, that's cool then! Why not simply include all this stuff with PHP rather than supporting the flawed ISAPI that it currently is packaged with? 4.3 the windows cgi binary is compiled with fastcgi support. I'm going to be testing the fastcgi on osx this week once I get thi

[PHP-DEV] Re: Windows Threads

John Coggeshall wrote: Shane (and everyone else): >Why don't we move PHP into a separate executable. Design a >"thin" ISAPI DLL which purely passes the data which the ISAPI >DLL exposes between the IIS process and the PHP process (or >process-pool for added reliability). The resulting page is

Re: [PHP-DEV] prototypes for getters and setters.

Alan Knowles wrote: Shane Caraveo wrote: >> >> >> Anyway before I get carried away and actually test this :) - anybody got >> any thoughts. >> >> Regards >> Alan > > > > > What's wrong with how overload does this? it has a

Re: [PHP-DEV] prototypes for getters and setters.

Anyway before I get carried away and actually test this :) - anybody got any thoughts. Regards Alan What's wrong with how overload does this? SHane -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PATCH] run-tests.php

This would make a simpler test, which would not need to rely on more advanced features like OO, which may change in their functionality once ZE2 comes around, as Marcus had pointed out. Since at this point we could have people running both ZE1 and ZE2 use the test, I think relying on OO is dang

Re: [PHP-DEV] Re: [PATCH] run-tests.php

Ok - so unless Shane disagrees and gets physical, /me jumps around screaming after hiking up a large mountain carrying 2 40lb. boulders...physical enough? :) run-tests.php should be in 4.3 and will have a totally different code-base than the version for php 4.4/5.0. I don't expect we'll b

Re: [PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions

I did more work and testing with fastcgi and apache 2, and have php 4.3 running under apache 2. Since it's out of process, no multithread issues which are one of the major issues. I didn't write docs, but there are some in sapi/cgi/README.fastcgi Shane As far as I can see, we should not not

Re: [PHP-DEV] RFC: run-tests.php & errors/warnings

The tests can only be performed using the cgi/cli sapis since they require a command line PHP binary. So, this is a non-issue. If we must display error messages then I would prefer using display_errors=1 instead of log_errors=1. Ilia I'm working with another person on a web version of the t

Re: [PHP-DEV] short_open_tag

Brad LaFountain wrote: It would be very bad for php if short tags were disabled. I 100% agree with andi. There are ways of dealing with xml and php without pissing off the WHOLE php user world. I don't even use long tags EVER, nor will I want to start. - Brad Damn, that comes from a SOAP develo

Re: [PHP-DEV] Work is beginning on cURL and PHP again

Sterling Hughes wrote: On Tue, 2002-10-22 at 01:38, Alan Knowles wrote: Non blocking connections would be nice... - On the generating stuff - why do you want to generate the code on the users system? - all the re2c stuff in CVS is 'pre-genereated' It would be nice to have extension generator

Re: [PHP-DEV] Work is beginning on cURL and PHP again

Sterling Hughes wrote: On Mon, 2002-10-21 at 22:15, Jon Parise wrote: On Mon, Oct 21, 2002 at 10:12:55PM +0200, Sterling Hughes wrote: * Autogenerating much of the interface between cURL and PHP, allowing PHP to support multiple versions of the underlying cURL library By what mechanism do y

Re: [PHP-DEV] Xerces?

Xalan and Xerces have both java and c versions. Markus Fischer wrote: > Since Xalan is written java, won't ext/java do that work > anyway? > > On Wed, Oct 16, 2002 at 02:56:50PM -0700, Alex Black wrote : > >>Hi all, >> >>I have done limited looking but as far as I can tell Xerces is no

re: [PHP-DEV] sapi/fhttpd + other sapi/cgi related things..

Seems I got unsubscribed and missed this email. sapi/fastgi is lacking in code that exists already in sapi/cgi, so I combined them several months ago. The idea is to depricate sapi/fastcgi in favor of the combined cgi/fastcgi module. libfcgi code from fastcgi.com is full of calls to exit() m

RE: [PHP-DEV] php_variables patch

Actually, I'm not sure when I'll be able to return to this so I'll just commit it since this is all working, and people can complain later if they want. Shane --- I'm working on getting mod_fastcgi/apache2/php4.3 to work together

[PHP-DEV] php_variables patch

I'm working on getting mod_fastcgi/apache2/php4.3 to work together smoothly. One thing mod_fastcgi does is, when it starts the fastcgi processes (php in this instance) very little environment is given to the process. The environment is sent via the fastcgi protocol for each request. To deal

[PHP-DEV] 4.3 fastcgi

I'd like to make sure fastcgi is well supported in 4.3. I spent some time over the weekend working on this and have some patches that I'll try to get into the tree in the next day or so. I haven't commited them yet as I am having problems getting it to work with apache2-win32/mod_fastcgi (a mod_

Re: [PHP-DEV] RFC: ODBC and PHP

through odbc2...odbc3 and so forth. Don't know an easy solution right now. Shane Dan Kalowsky wrote: > On Tue, 10 Sep 2002, Shane Caraveo wrote: > > >>Hmm, is there no way to make the functions work with both odbc versions? >> Have an odbc_set_version(int) function that can

Re: [PHP-DEV] RFC: ODBC and PHP

Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. Shane Dan Kalowsky wrote: >

Re: [PHP-DEV] sockets extension...pecl it

Dan Kalowsky wrote: > Because the user can see how active such functionality is by looking at > the CVS logs, and doing a search on php-dev conversations. Sorry, but that's a copout. It expects way to much of the user. If it's going to remain experimental, OR the api is going to continue to c

Re: [PHP-DEV] mbstring

Jim Winstead wrote: > Yasuo Ohgaki <[EMAIL PROTECTED]> wrote: > >>Marcus B?rger wrote: >> >>>We already had some discussion on some IF statements in ini >>>files already. I guess we might call to another mail thread here >>>and hope we find a volunteer. I will not invent any work here since >>>th

Re: [PHP-DEV] ISAPI Crash Debugging Notes

> Either way - starting threads from an ISAPI filter/extension is > completely forbidden (or at least strongly discouraged) so even if there > is some bug in there, starting our own thread is not an option. Can you > give me the data I mentioned in the previous letter? > > Zeev It's not forb

Re: [PHP-DEV] PHP 4.3 and PHP 5

Rasmus Lerdorf wrote: > But how do you propose we come up with perfect Apache 2.0 support? FastCGI :) > If we > limit it to the pre-fork mpm, we can probably get quite close to perfect > stability, but for any of the threaded mpms we are completely at the mercy > of the threadsafetyness of all

Re: [PHP-DEV] PHP 4.3 and PHP 5

> > > > o Decide if we are or are not going to support the iPlanet system. If we >are, it needs to be drastically fixed, if we're not we need to drop it. >Really. Look at the bug reports. > > It should simply be marked EXPERIMENTAL, but not removed. On the other hand, it doesn't have to be i

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

> > It took us a long time to get php-dev@ moving on the new version > because most of them were still using PHP 3 for their production sites. > The fact that you guys are so strongly in favor of putting this cool > feature into ZE1 proves that not putting it in could give ZE2 a big > boost of

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

Thies, just commit the patch and let this thread die. Shane -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted

Wez, I haven't looked into the streams stuff much, but have had it in the back of my head a lot. Does the streams implementation support 'filters' on streams? With this, whatever gets written to a stream would go through a filter prior to going across the wire. Reason I ask is that this wou

Re: [PHP-DEV] phpthreads - hints anyone...

Andi Gutmans wrote: > I still think that if you're going to implement such a thread extension > it shouldn't try and copy it's parents data-structures. It'd be very > slow and prone to errors. Andi, Currently only the thread_include function that Alan wrote works. I have idea's for doing the

Re: [PHP-DEV] phpthreads - hints anyone...

Andi Gutmans wrote: > At 12:40 PM 8/3/2002 -0700, Shane Caraveo wrote: > >> Andi Gutmans wrote: >> >>> By the way, if we do end up making this kind of thing mainstream we >>> should probably use APR (or another library) for thread abstraction. >>>

Re: [PHP-DEV] phpthreads - hints anyone...

I've cleaned things up a bit, removed code from tsrm and added it to a new file, and commited to pecl. This way those interested can start playing with and developing the module. Shane -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] phpthreads - hints anyone...

Andi Gutmans wrote: > By the way, if we do end up making this kind of thing mainstream we > should probably use APR (or another library) for thread abstraction. I > wouldn't want to do all of that work over. > > Andi > That would be nice, but not sure how realistic at this point. Idealy, we

Re: [PHP-DEV] phpthreads - hints anyone...

Alan Knowles wrote: > Ok, had a play with this > updated copy on > http://docs.akbkhome.com/threads.tgz > > added a few of pthreads calls to TSRM.c > > did most of the testing without this abstraction layer - just to see if > I could get it to work. > > used php_exectute_script, rather than ge

Re: [PHP-DEV] phpthreads - hints anyone...

Alan Knowles wrote: > Ok, had a slight play with it again.. > > I did eventually find the perl code for threading although without an > lxr server it's pretty much impossible to decipher all the macros they > use.. It's not about looking at the perl code, that will tell you nothing unless you

Re: [PHP-DEV] phpthreads - hints anyone...

Alan Knowles wrote: > Im looking at adding threading to php, (for the cgi/cli stuff).. > > The story so far: > > I've created an extension which diverts all zend_execute calls into the > extension -> phpthreads_execute. > this function is a copy of zend_execute with a few modifications > - to c

Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT

Shell Shortcuts could be used to implement symlink like behaviour, and it would be compatible on more systems, but it would be a bigger pain to implement in PHP. As far as the directory junctions, this is how MS describes them: # NTFS Directory Junctions. These are NTFS directories that can be

Re: [PHP-DEV] Komodo (PHP) Intergrated Development Environment Problems

Hi Jason, PHP-DEV isn't the proper forum for asking questions about commercial products. Email us on the komodo-discuss email list, email list info at http://aspn.activestate.com/ASPN/Downloads/Komodo Regards, Shane Caraveo Jason McCormack wrote: > Hi All, > > Has anyone out

[PHP-DEV] flock on windows

Just a question and comment since I've been looking into php's flock on windows. First, the documentation states 'When using a multithreaded server API like ISAPI you may not be able to rely on flock() to protect files against other PHP scripts running in parallel threads of the same server i

Re: [PHP-DEV] PECL != Siberia

S. Bakken wrote: > You tell me :) We currently have no nice way of bootstrapping PEAR on > Windows like we have on Unix (with "make install-pear-installer" and > go-pear). What would be the most sensible way of giving Windows users > something ala go-pear? > > - Stig >

Re: [PHP-DEV] PECL != Siberia

Hmm, what is happening for win32? Stig S. Bakken wrote: > With the latest PEAR installer (version 0.90), PECL extensions are now > built and installed during "pear install/upgrade" on Unix systems. > > First: upgrade PEAR to 0.9 with "pear upgrade PEAR". > > If you have the xmms libraries a

Re: [PHP-DEV] PHP's vision

> Making PHP work a certain way because a specific platform doesn't have the > different items should not be a deciding factor. wrong. It's absolutely a major factor. Shane -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] libxml bundling

> > I indeed like to see some proof that it is used so widely. You state that > XML is widely used, but I really think that this is only true for a small > part of the people who work with PHP. This does not mean I don't see value > in XML, it's certainly usefull... but that doesn't warrant b

Re: [PHP-DEV] PHP's vision

Markus Fischer wrote: > On Sun, Jun 02, 2002 at 04:21:48PM +0200, Sebastian Bergmann wrote : > >>Jani Taskinen wrote: >> >>>I'm not that familiar with Java..so it would be nice to hear >>>what Java offers that PHP doesn't? >> >> And coming back to the original topic of this thread: perfect supp

Re: [PHP-DEV] PHP's vision (was: libxml bundling)

> > The PHP project does not exist to create the perfect incarnation of a > computer language on the planet, for CS majors to drool over and utter > 'Wow!' at. It exists as a quick, powerful platform for creating web > sites, in use by hundreds of thousands of people around the world. For

Re: [PHP-DEV] libxml bundling

[EMAIL PROTECTED] wrote: > On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: > > [...] > > >>I wish it became a default module, too. > > > Sure, lets enable everything by default then. ODBC is very important too, > and of course also encryption, so we need mcrypt and mhash, or the very > important FT

Re: [PHP-DEV] bundling libxml2 / bundling locations

In regards to download size, I took a look at other languages: perl 6mb source python 6mb source activeperl 8.5mb binary activepython 7mb source, binaries are larger activetcl 8.5mb I don't think the increase of a half mb in php source size is that big a deal, esp. for something as important as

Re: [PHP-DEV] bundling libxml2 / bundling locations

>> lot I'd >> > be a +1. If it'd add 1 MB to our .tar.gz I would be against. >> >> THe normal source distribution is almost 2 MB... > > > In that case I'm against :) > > Andi xpat is 300K. If Brad can get it down to 500K, and we replace xpat, then we realy are not growing all that much. I'

Re: [PHP-DEV] bundling / PECL

> > I think the solution would be to allow PECL to optionally fetch the > libraries an extension depends on, quite like FreeBSD ports. > > It is exactly as much work as bundling them altogether, of course, > but at least we avoid the impact on our distribution size. > > mk > Actually, this is

[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV][RESENT] [PATCH] Allow constants / expressions to be passed by reference]

Ahh yes, I've been bitten by this limitation a few times, quite agravating. I would definitly like to have this work. Shane phpsurf wrote: > the problem is that if you define some function : > > function someFunc(&myParam) { > ... > } > > then you can call : > someFunc($someVar); > > but

Re: [PHP-DEV] PECL vs. CORE .... from a users perspective

Michael Dransfield wrote: > > 1: I assume that for the ext's that are dropped from core and added to > PECL, the extension line will be dropped from the ini file and users > will need to use some kind of 'use EXT::Extension' command. Will there > be a way to override which extensions will nee

Re: [PHP-DEV] PECL vs. CORE .... was msession

hane Vlad Krupin wrote: > +1. > Except EXPERIMENTAL ones. If an extension belongs in the CORE, it makes > no sense to stuff it in PECL and then move back to core once > EXPERIMENTAL status is dropped. > Vlad > > > Shane Caraveo wrote: > >> > I would like reinst

Re: [PHP-DEV] PECL vs. CORE .... was msession

> I would like reinstatement of msession into the main tree, and if you oppose I would like a serious > discussion to take place on the developer list. If you support it, I need you to sound in on the > discussion. Well, I feel like 80%, if not more, of the extensions should move to PECL, l

[PHP-DEV] soap email list

Everyone who subscribes, please send an email to the list so we know. Thanks, Shane -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL

So this is what I propose... setup [EMAIL PROTECTED] for further conversation. As a starting point PEAR::SOAP is a script wrapper around a C level extension. It's available in absence of the C extension, and for additional features that don't make sence to implement in C, or for fast exten

Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL

Unless some work has been done on it, I found it very lacking. Many things are hardcoded in C that would make it hardly interoperable with other implementations. Shane > In fact, xmlrpc-epi also supports SOAP: > > ---[SNIP]--- > As of Sept. 27, 2001, experimental support for SOAP v 1.1 has b

  1   2   >