Hi Greg,
Actually it is possible to have both installed. Just make sure all php4
files
are in the same directory, say c:\php4\php432 including your php.ini, while
the php.ini in the windows directory is for php5.
Regards, John
"Greg Beaver" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTEC
Zitat von Jani Taskinen <[EMAIL PROTECTED]>:
>
> Works fine here, get a fresh checkout.
Doh! You shouldn't try to run the tester if you compiled --without-cli. ;-)
> --Jani
>
> On Wed, 2 Jul 2003, Jan Schneider wrote:
>
> >/bin/sh: line 1: /home/jan/software/php43/: is a directory
> >mak
> It's not an annoyance - it's not my spec, I'm just implementing it.
> I'm happy to change the code to work via properties instead, it's not a
> major change. I would like to settle on a concensus first.
+1 (maybe both)?
>
> George
>
--
PHP Internals - PHP Runtime Development Mailing Li
On Wed, 2 Jul 2003, Gabor Hojtsy wrote:
> > Does anybody object if I remove the php-4.3.0-dev-zend2-* files from
> > phpweb/distributions ? This saves atleast 20mb...
>
> +1 :)
done
Derick
--
"Interpreting what the GPL actually means is a job best left to those
that read
fixes building under windows.
Uses TSRMLS_FETCH().
Not sure if there is a better way.
Index: zend_reflection_api.c
===
RCS file: /repository/ZendEngine2/zend_reflection_api.c,v
retrieving revision 1.8
diff -u -r1.8 zend_reflection_
Hello Zeev, hi Andi,
attached is my idea of finally fixing the destructor visibility. It simply
emits an E_ERROR on an illegal attempt to destruct an object during execution
and emits an E_WARNING with a slighlty longer message in shutdown (outside
execution). Patch attached.
--
Best regards,
On Tue, 01 Jul 2003, Timm Friebe wrote:
> - Added Reflection_Class::getModifiers which returns a long
> consisting of the bitmask of modifiers which are registered
> as constants with the following names:
>
> STATIC
> ABSTRACT
> FINAL
> INTERFACE
> ABSTRACT_CLASS
> FINAL_CLASS
>
On Wed, 02 Jul 2003, Timm Friebe wrote:
> On Wed, 2003-07-02 at 05:32, Timm Friebe wrote:
> [...]
> > This should now be the final patch.
>
> Then again, it would help to attach it:)
Why aren't you using the standard zend_parse_parameters() API function
here?
-Andrei
* It's an emergent property
On Wed, 02 Jul 2003, Andi Gutmans wrote:
> I've already said so, but I definitely prefer methods.
So do I. Overloading properties is a bit of magical powder that's
appropriate only in some cases.
-Andrei
* There is no knowledge that is not power. -- Ralph Waldo Emerson *
--
PHP Internals - PHP
Not sure if this interest anyone, but the attached patch adds a function
called var_dump_html() that performs the same functionality as
var_dump(), except that it outputs HTML instead of plain text.
var_dump() is a bit impractical to use in a web environment, IMO.
Cheers,
Marco
--
Marco Tabin
On Thu, 3 Jul 2003, Marco Tabini wrote:
> Not sure if this interest anyone, but the attached patch adds a function
> called var_dump_html() that performs the same functionality as
> var_dump(), except that it outputs HTML instead of plain text.
> var_dump() is a bit impractical to use in a web env
Quoting Derick Rethans <[EMAIL PROTECTED]>:
> On Thu, 3 Jul 2003, Marco Tabini wrote:
>
> > Not sure if this interest anyone, but the attached patch adds a function
> > called var_dump_html() that performs the same functionality as
> > var_dump(), except that it outputs HTML instead of plain text
My only consideration is that most people use var_dump in a web
environment--hence it seems counterintuitive to have to enclose the
function in additional HTML tags.
Cheers!
On Thu, 2003-07-03 at 11:09, Derick Rethans wrote:
> On Thu, 3 Jul 2003, Marco Tabini wrote:
>
> > Not sure if this intere
In my opinion is good idea but Derick has rason, is better if var_dump_html
colorise the output :-)
- Original Message -
From: "Marco Tabini" <[EMAIL PROTECTED]>
To: "Derick Rethans" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, July 03, 2003 5:13 PM
Subject: Re: [PHP-DEV] var
What could it possibly colorize and how would it be useful?
epplestun wrote:
In my opinion is good idea but Derick has rason, is better if var_dump_html
colorise the output :-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I still fail to understand how this would be helpful to someone who's
debugging a script (as I presume you're not showing the user nicely
colorised var_dump()s). *shrug*
Vlad
Ken Tossell wrote:
Quoting Vlad Bosinceanu <[EMAIL PROTECTED]>:
What could it possibly colorize and how would it be
Marco Tabini wrote:
> Not sure if this interest anyone, but the attached patch adds a function
> called var_dump_html() that performs the same functionality as
> var_dump(), except that it outputs HTML instead of plain text.
> var_dump() is a bit impractical to use in a web environment, IMO.
Plea
Hello internals,
It is of course correct that an interface method cannot be declared private
but i think it should be possible to declare it protected.
Best regards,
Marcus mailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On Thu, 2003-07-03 at 11:47, Frank Wiegand wrote:
> Marco Tabini wrote:
>
> > Not sure if this interest anyone, but the attached patch adds a function
> > called var_dump_html() that performs the same functionality as
> > var_dump(), except that it outputs HTML instead of plain text.
> > var_dump(
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Hello internals,
>
> It is of course correct that an interface method cannot be declared private
> but i think it should be possible to declare it protected.
I don't see the benefit to allow interfaces to have protected methods as I
use abstracts for t
Zitat von Moriyoshi Koizumi <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] (Marcus Börger) wrote:
>
> > Hello internals,
> >
> > It is of course correct that an interface method cannot be declared
> private
> > but i think it should be possible to declare it protected.
>
> I don't see the benefit to all
Hello Jan,
Thursday, July 3, 2003, 6:15:04 PM, you wrote:
JS> Zitat von Moriyoshi Koizumi <[EMAIL PROTECTED]>:
>> [EMAIL PROTECTED] (Marcus Börger) wrote:
>>
>> > Hello internals,
>> >
>> > It is of course correct that an interface method cannot be declared
>> private
>> > but i think it should
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Not really. An interface simply describes a protocol subset that must be part
> of the implementing class's protocol. In that it makes no sense to allow final
> or private methods in an interface but still a protected member in an interface
> would descri
Hello Moriyoshi,
Thursday, July 3, 2003, 6:50:46 PM, you wrote:
MK> [EMAIL PROTECTED] (Marcus Börger) wrote:
>> Not really. An interface simply describes a protocol subset that must be part
>> of the implementing class's protocol. In that it makes no sense to allow final
>> or private methods in
Marco Tabini wrote:
>> Please have a look at PEAR::PHP::Var_Dump:
>> http://pear.php.net/package-info.php?pacid=103
> Thanks, Frank, I have. But do I really want to load up a PEAR class to
> dump my variables to the browser? For me, the answer is no--although,
> obviously, that is only my opinio
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Nice idea, but one thing i wanted is to disable cloning of class objects.
>
> The following class makes cloning impossible for all derived classes:
> class no_clone {
> final private __clone() {}
> }
>
> but the all classes that should not be cloned m
Hello Moriyoshi,
Thursday, July 3, 2003, 7:13:44 PM, you wrote:
MK> [EMAIL PROTECTED] (Marcus Börger) wrote:
>> Nice idea, but one thing i wanted is to disable cloning of class objects.
>>
>> The following class makes cloning impossible for all derived classes:
>> class no_clone {
>> final pr
On Thu, 2003-07-03 at 13:09, Frank Wiegand wrote:
> IMHO its not PHP's job to produce HTML output for debugging purposes.
Well, then, I guess we'll have to agree to disagree. IMO, PHP's job is
to work in a way that is most useful to the developer. Since most
developers use PHP in web projects, it
* Marco Tabini wrote:
> Thanks, Frank, I have. But do I really want to load up a PEAR class to
> dump my variables to the browser? For me, the answer is no--although,
> obviously, that is only my opinion.
Normally one would dump to an error_log (and having
a tail -f php_error.log in another shell)
On Thu, 2003-07-03 at 13:33, Björn Schotte wrote:
> Normally one would dump to an error_log (and having
> a tail -f php_error.log in another shell), not to the browser.
> If one has a small web package, he could do "" ... "",
> so there shouldn't be any problem.
Yes, but--
(a) Not everybody does
* Marco Tabini wrote:
> (a) Not everybody does it that way
That's no argument.
> (b) Not everybody *can do it* that way--think Windows users.
Cygwin exists and I'm sure there's a bunch of freeware/shareware
tools that do the same.
--
ThinkPHP und Partner auf dem LinuxTag. Seien Sie mit dabei,
On Thu, 2003-07-03 at 13:43, Björn Schotte wrote:
> * Marco Tabini wrote:
> > (a) Not everybody does it that way
>
> That's no argument.
Well, how can I argue with this?
> > (b) Not everybody *can do it* that way--think Windows users.
>
> Cygwin exists and I'm sure there's a bunch of freeware/
* Marco Tabini wrote:
> So, your position is that a developer should bend to the technology.
No. My position is that a developer should evolve and learn
that there are some more professional ways than just dumping
debug data to the browser instead of a log file.
--
ThinkPHP und Partner auf dem L
On Thu, 2003-07-03 at 13:49, Björn Schotte wrote:
> * Marco Tabini wrote:
> > So, your position is that a developer should bend to the technology.
>
> No. My position is that a developer should evolve and learn
> that there are some more professional ways than just dumping
> debug data to the brow
Marco Tabini schrieb:
> A two-liner is twice as many lines as a one-liner :-) .
Thats why I pointed to auto_prepend_file.
> In a debugging
> situation, you often add and remove var_dump()'s quickly and all over
> the place while hunting down a bug. Having to worry about an extra step
> uselessly
smime.p7s
Description: S/MIME Cryptographic Signature
Sorry, I'll try again
Why is dumping debug to the log more professional??
When I want debug information, I usually want it quick. It takes 2
seconds to add a var_dump or whatever, upload the change, and reload the
page. Whatever gets the job done quickest seems more professional to me.
Best re
Can you guys take this thread off the internals@ list please.
- Original Message -
From: "Fred Merritt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 03, 2003 7:16 PM
Subject: Re: [PHP-DEV] Re: var_dump_html()
> Sorry, I'll try again
> Why is dumping debug to the log m
* Marco Tabini wrote:
> On Thu, 2003-07-03 at 13:49, Björn Schotte wrote:
> > No. My position is that a developer should evolve and learn
> > that there are some more professional ways than just dumping
> > debug data to the browser instead of a log file.
> Please, do not imply that what I am sugge
On Thu, 2003-07-03 at 15:31, Björn Schotte wrote:
> If so, then I would suggest the following add-ons:
Whatever. :-)
The patch is out there. I wrote because I found it useful. If others
find it useful as well, so much better. I see no value in this
discussion, and no reason to keep cluttering the
Maybe we should just not allow access modifiers for the destructor. It
doesn't make very much sense and we don't "promise" destruction at a
specific point in time.
Andi
At 03:07 PM 3/7/2003 +0200, Marcus Börger wrote:
Hello Zeev, hi Andi,
attached is my idea of finally fixing the destructor vi
On Thu, Jul 03, 2003 at 03:36:58PM +0200, moshe doron wrote:
> > It's not an annoyance - it's not my spec, I'm just implementing it.
> > I'm happy to change the code to work via properties instead, it's not a
> > major change. I would like to settle on a concensus first.
>
> +1 (maybe both)?
At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote:
Hello internals,
It is of course correct that an interface method cannot be declared private
but i think it should be possible to declare it protected.
Interfaces should not support access modifiers and should by default be public.
Andi
--
PHP Int
At 06:40 PM 3/7/2003 -0400, Jon Parise wrote:
On Thu, Jul 03, 2003 at 03:36:58PM +0200, moshe doron wrote:
> > It's not an annoyance - it's not my spec, I'm just implementing it.
> > I'm happy to change the code to work via properties instead, it's not a
> > major change. I would like to settle o
At 01:51 AM 4/7/2003 +0200, Andi Gutmans wrote:
At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote:
Hello internals,
It is of course correct that an interface method cannot be declared private
but i think it should be possible to declare it protected.
Interfaces should not support access modifiers an
Hello Andi,
Friday, July 4, 2003, 1:35:58 AM, you wrote:
AG> Maybe we should just not allow access modifiers for the destructor. It
AG> doesn't make very much sense and we don't "promise" destruction at a
AG> specific point in time.
On one hand it would of course be an option which simplifies
Hello Andi,
Friday, July 4, 2003, 1:53:48 AM, you wrote:
AG> At 01:51 AM 4/7/2003 +0200, Andi Gutmans wrote:
>>At 06:03 PM 3/7/2003 +0200, Marcus Börger wrote:
>>>Hello internals,
>>>
>>>It is of course correct that an interface method cannot be declared private
>>>but i think it should be possib
having had a quick think about this, here some thoughts that may affect it.
What is the API going to be used for.
a) replacement for method_exists(), call_user_func() in code
.. which makes sense for the object methods...
b) quick testing of what an interface is - as in print_r() is quicker
than o
Hello internals,
during my todays work i was again reminded that still one array function is
missing namely array_has_more. This function will return true if there are
more elements in an array and false if not. The real problem is that next()
doesn't work with false.
A diff against PHP 5 is at
I've got Apache 1.3.27 with PHP 4.3.0 on NetBSD 1.5.3. When a PHP
program running in safe mode calls the mail() function to send
mail, the usual Apache environment variables like SCRIPT_FILENAME
and REMOTE_ADDRESS are not exported. This is a problem since I
need to log which CGI and remote host a
Andi Gutmans wrote:
> Interfaces should not support access modifiers and should by default be
> public.
+1
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Interna
51 matches
Mail list logo
