Mozilla uses autoconf/make and a few other things from cygwin, but uses
the ms compiler/linker. It would be interesting to see that for php,
then there would be a single build system rather than two.
Anway, an additional item with the new toolkit, it requires
redistribution of msvcr7.dll or
Zeev Suraski wrote:
At 13:28 19/04/2004, Christian Schneider wrote:
Zeev Suraski wrote:
1. First of all, I agree that in a perfect world we should go with
E_COMPILE_ERROR for everything. Maybe now that's constructors are out
I'm not sure I understand what you mean by everything.
seems sqlite.w32.h did not get updated when sqlite was last updated, so
you cannot build a clean php5 on win32. The culprit is the
SQLITE_NOTADB define. hacking it in at least lets me build...this is on
a newly installed xp pro box, where I have only compiled 4.3.x so far.
Shane
--
PHP
just need updating.
At 12:33 PM 7/14/2004 -0700, Shane Caraveo wrote:
Using the dsp. If the dsp files will not be supported, then they
should be removed.
Shane
Wez Furlong wrote:
Using .dsp build, or the new build system?
On Tue, 13 Jul 2004 22:03:17 -0700, Shane Caraveo [EMAIL PROTECTED]
wrote
Here is my suggestion,
Rather than taking two switches, php should grow a generic switch for
this kind of use:
php -o param:value;param:value;
This allows custom mods to php a way to introduce new options that are
not part of the general php distribution, without the need to land grab
the
Rasmus Lerdorf wrote:
On Tue, 26 Oct 2004, Wez Furlong wrote:
It should be safe to never ever dlclose() a module.
Do you mean never to dlclose() a module loaded via dl() at request time or
do you mean that in general it should be safe to never dlclose() a module
even if it came in via an
Not a real suggestion, but a comment on this...
There is no reason to use dylib for libraries that will only be loaded
by php. the php library itself should be .dylib, by php extensions
*can* be .so. Python works this way. However, I'm not convinced it's
the best thing, as it does lead to
Rasmus Lerdorf wrote:
On Sun, 31 Oct 2004, moshe doron wrote:
where the problem about 'taking it ever further'? I'm +1 for {-1}
and more +1 for {-4,2} python likeness.
That starts getting confusing.
Having my python hat on...
(some of this is just general comment after reading too much of this
Rasmus Lerdorf wrote:
Andi Gutmans wrote:
I definitely like the idea and thing it's important.
I think as far as the filter functions are concerned this is a good
way to go (although I'd change the function name but that's no biggy,
filter_input?). I very much see how filter_input(POST, email,
that I'm missing something?
Moriyoshi
Shane Caraveo [EMAIL PROTECTED] wrote:
I've been compiling all day with no problem. I'll do a clean build and
make sure about that.
Shane
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sterling Hughes wrote:
Hi,
Since we're all working on php5-dev now, i think its time to update the
apache module name of php to php5_module or php_module (I'm for the
latter).
I'll go ahead and do this tommorow unless someone objects.
-Sterling
This should be done for everything I think (such
Stanislav Malyshev wrote:
DR But it *is* confusing (just as function() { function() {} }, but of
DR course we can not change that anymore). What is the reason of
DR allowing this 'nested' stuff?
Because someone asked for it. I don't see why it is so bad.
That's a bad reason for a bad feature.
Rasmus Lerdorf wrote:
On Wed, 26 Mar 2003, Shane Caraveo wrote:
Rasmus Lerdorf wrote:
Couldn't you make the same argument for:
function A() {
function B() {
}
}
I would :)
The syntax is meaningless and confusing if the program does not operate
the way it is written. By all sensible
David Hill (php.net) wrote:
Hi,
back on reentrancy I know that with some of the libraries the extensions
depend on are not reentrant (ie. also not thread safe). The imap library cclient comes
to mind (unless something has changed recently) and I know gettext caches data in
global
Andi Gutmans wrote:
At 09:42 AM 3/27/2003 -0800, Shane Caraveo wrote:
Well, if set_error_handler could catch E_ERROR errors (and not bail),
then errors could be changed to exceptions in user space. I already
use this in the soap library to catch invalid parameters, which I
beleive are only
I want to start de-versioning our filenames (for example php4isapi.c to
php_isapi.c) and project files (dsp files on win), and change built
files to php5xxx where apropriate. I would do it using:
$ mv old new
$ cvs remove old
$ cvs add new
$ cvs commit -m Renamed old to new -r x.x old new
(-r
James Cox wrote:
So now that the PEAR framework for bundling extensions is in
place, I figured I'd start a thread about moving all
extensions to PECL, and then selectively bundling them from
PECL (perhaps maintaining physical aliases as well.)
I'm +1 on this.. And already offered to move
Marcus Börger wrote:
Some extensions like mbstring behave different when not builtin. So
i suggest we find out which theses are and let them in.
Having them in pecl in no way prevents them from being compiled builtin.
Also for extensions like ext/gd i don't see any reason to move them
out of
+0 While I really like the idea, auto-exceptions for errors would mess
up library code that isn't written to use exceptions. If that problem
can be dealt with correctly, then I'd be +1. Otherwise, we need a new
error level.
Shane
Marcus Börger wrote:
Hello Sterling,
We need exceptions
I knew I should have kept my mouth shut...
Marcus Börger wrote:
Hello Shane,
just to repeat there weren't any exceptions in php4
Yes, you don't have to tell me the obvious.
and the things
that'll use exceptions in php5 will require full rewrite anyway. So i
don't see any problem.
try {
George Schlossnagle wrote:
try {
function_call_to_some_preexisting_library_that_doesnt_do_exceptions()
} catch(e) {
}
The auto-generated exceptions can be of type InternalException extends
Exception {}, and then the caller can decide whether or not they want to
comply with the old method
After long amounts of reading
+1
However, I'd like to see sqlite remain in PECL, and start using PECL the
way it should be. That would be a good start. I think it would ease
some minds, and point out whatever areas happen to still be *real*
issues (if any).
Shane
--
PHP Internals - PHP
Sebastian Bergmann wrote:
With all this new fancy XML support in PHP 5 -- what about SOAP?
I plan on implementing a new soap library based on top of simplexml, but
will not be able to start serious work on it until august. The new
library would be usable with almost no PHP code, but will
Rasmus Lerdorf wrote:
On Sun, 29 Jun 2003, Steven Brown wrote:
Does this mean that non-GPL projects written in PHP will soon have to
buy a license for MySQL or migrate off it?
Yes, pending some sort of excemption/additional rights clause from MySQL
AB which would permit these projects to do so,
The problem is one of simplicity ;)
I ran into the same problem a couple days ago. In the two examples, an
array of element 'child' is expected. That array may be one or more
elements. SimpleXML turns multiple children of the same element name
into array's, but a single child is not. I'm
Marcus Börger wrote:
Hello Sebastian,
Friday, September 5, 2003, 5:45:13 PM, you wrote:
George Schlossnagle wrote:
Forcing all thrown objects to be subclassed from Exception does not
feel very PHP-ish.
In this case I think that right-ish should outweigh PHP-ish.
right-ish...well why not
I'll be able to do a quick review of it while I'm sitting in the airport
in Seattle tonight.
Shane
Andi Gutmans wrote:
I have no problem with you committing this. It'd be good if at least
another guy who has been working on the new XML extensions gives you
thumbs up.
Andi
At 02:36 PM
hmm...not that Rob needs a thumbs up from me, I'm just another pair of
eyes a little familier with it.
Shane
Shane Caraveo wrote:
I'll be able to do a quick review of it while I'm sitting in the airport
in Seattle tonight.
Shane
Andi Gutmans wrote:
I have no problem with you committing
+1 for the [] syntax. I also feel it's much more intuitive. Calling
(what looks like) a function to make an array seems plain silly to me.
Shane
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
11/6/2003 -0800, Shane Caraveo wrote:
I've also done a touch of slides on it, as has Sterling, and maybe
even someone else, at talks.php.net. Nothing terribly in-depth.
Shane
Christian Stocker wrote:
My slides from my talk about XML in PHP5 are here:
http://slides.bitflux.ch/phpconf2003
Adam Maccabee Trachtenberg wrote:
On Tue, 11 Nov 2003, John Coggeshall wrote:
I know Shane was working on some major improvements to simplexml that I
don't know if he's finished yet. Sterling didn't seem to have any
interest in really finishing the code he did write from our
conversations.
I
John Coggeshall wrote:
To be honest, I think the answer is somewhere in the middle. Basically, the
engine is done. I think the XML extensions and SQLite are pretty mature,
I know Shane was working on some major improvements to simplexml that I
don't know if he's finished yet. Sterling didn't
Derick Rethans wrote:
On Tue, 11 Nov 2003, Shane Caraveo wrote:
Adam Maccabee Trachtenberg wrote:
On Tue, 11 Nov 2003, John Coggeshall wrote:
I know Shane was working on some major improvements to simplexml that I
don't know if he's finished yet. Sterling didn't seem to have any
interest
Zeev Suraski wrote:
My suggestion - we'll work on fixing ZE2 bugs (*). Fix as many as we
can as soon as possible, and aim to release on Dec 15. Worst case -
we'll delay to Xmas. If enough changes accumulate - we can have B3 too,
but I'm not sure it will be necessary, because the betas don't
While I dont care if the name changes for php5, I dont buy the premise
that more and more people will be using php outside the web. I think
cli has it's uses, but I think it will be a marginal group of people who
make large use of it.
Shane
Wez Furlong wrote:
If you need to configure php5
I haven't read this whole huge thread, but I agree with Sterling in this
aspect. If the problem of children and attributes can be addressed
without functions, it should be done that way. DOM is not that overly
complex or with much overhead in the way it's been implemented. If
people need full
Why is PHP the only scripting language that has an issue with loading
binary extensions at run time? :(
Shane
Ard Biesheuvel wrote:
Wez Furlong wrote:
I agree; we can't deprecate dl().
There are some very common legitimate cases where it is really
useful, such as loading extensions that are
Stanislav Malyshev wrote:
PJ python in my case. And not only langages, please check any tools that
PJ allows dynamic load of extensions.
Most languages even don't have a concept of extensions,
WTF? At least I get a good laugh early in the morning.
Perl, Python, Tcl, Pike, Ruby, *name you
Zeev Suraski wrote:
At 17:27 11/02/2004, Shane Caraveo wrote:
Arguments for this have been gone over in the past and generaly
'security issues' and 'memory usage' are used as reasons to not change
the way it works, both being generaly bogus. The only reason it isn't
fixed is reliance
Ilia Alshanetsky wrote:
On February 11, 2004 11:20 am, Shane Caraveo wrote:
2. php's dl implementation is broken by design, it should never unload a
dl. not only is that a performance issue, but it requires all kinds of
code to verify that the dl CAN be unloaded properly, thus the problem
Zeev Suraski wrote:
At 18:20 11/02/2004, Shane Caraveo wrote:
Zeev Suraski wrote:
At 17:27 11/02/2004, Shane Caraveo wrote:
Arguments for this have been gone over in the past and generaly
'security issues' and 'memory usage' are used as reasons to not
change the way it works, both being
41 matches
Mail list logo
