php-windows Digest 5 Feb 2010 13:49:44 -0000 Issue 3754
Topics (messages 29845 through 29850):
Re: A way available to test PHP CGI builds.
29845 by: Pierre Joye
29846 by: Venkat Raman Don
29847 by: Ferenc Kovacs
29848 by: Venkat Raman Don
29849 by: Pierre Joye
Re: What about php 5.3 and printers or PHP_PRINTER.DLL ?
29850 by: Keith Davis
Administrivia:
To subscribe to the digest, e-mail:
php-windows-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-windows-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-wind...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
hi,
Let me start from scratch:
To test the output of a http request, no browser is required. PHP
alone suffices, or wget/curl cmd line (or other similar tools). PHP
supports HTTP (incl. headers), the diff can be generated easily, see
run-tests.php.
The only reason why a browser would be required is to compare the
visual output or how js behaves. That's where GD could help, to
compare screenshots of the rendered page. But that's not what we neeed
here.
That's what I was trying to explain.
Cheers,
--
Pierre
On Tue, Feb 2, 2010 at 7:37 AM, Venkat Raman Don
<don.ra...@microsoft.com> wrote:
> Hi,
>
> Let's don't argue just for the heck of it.
>
> Can I know why browser is not a good thing. And what solution you are
> arriving into. And can you help me share the coding for that solution if we
> find it better. And BTW my solution doesn't involve comparing screenshot.
>
> I think I have given enough reason why not to use GD/COM. Do you still think
> using COM/GD is a viable option? Or you have another alternative? I already
> told you we can use Mozilla based browser which can be used across platform.
> Ideally a solution should be scalable and work on different matrix.
>
> Thanks,
> Don.
>
> -----Original Message-----
> From: Pierre Joye [mailto:pierre....@gmail.com]
> Sent: Monday, February 01, 2010 1:04 PM
> To: Venkat Raman Don
> Cc: php-wind...@lists.php.net
> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>
> On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
> <don.ra...@microsoft.com> wrote:
>> Hi,
>>
>> A good idea about using COM/GD. Let's talk about some pro/cons of it and the
>> solution I gave.
>> 1. COM never worked with default IIS configuration because of permission
>> issues. This means again you are not simulating a real world scenario.
>> 2. COM based solution will never have the ability to be ported to UNIX world.
>> 3. GD can be used for screenshot comparison but any screenshot comparison
>> will have some error of margin. Plus your thing (expected output) will be
>> dependent on screen resolution/display settings etc. If your code has to be
>> portable going this route is not a good idea in my view.
>>
>> Regarding dependency on IE, I see no reason why we cannot use a Mozilla
>> based browser and automate it. That way it can work on any platform though
>> it will have its own challenges but not the ones we will face using GD and
>> COM.
>
> Sorry, I was not clear. My point was: There is no need of a browser to
> do http requests and compare the output.
>
> For test client side results (visuallly, js, etc.), there are
> excellent tools out there like selenium, but that's not what we
> discuss here.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--- End Message ---
--- Begin Message ---
Hi,
Pierre, I understand that there are alternate ways. I was just asking why the
browser way is bad or not acceptable? Or you are okay with browser way and
suggesting an alternative. If you have concerns regarding using browser to
test, I would like to know it as it also impacts WINCACHE quality overall.
Thanks,
Don.
-----Original Message-----
From: Pierre Joye [mailto:pierre....@gmail.com]
Sent: Tuesday, February 02, 2010 1:21 AM
To: Venkat Raman Don
Cc: php-wind...@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
hi,
Let me start from scratch:
To test the output of a http request, no browser is required. PHP
alone suffices, or wget/curl cmd line (or other similar tools). PHP
supports HTTP (incl. headers), the diff can be generated easily, see
run-tests.php.
The only reason why a browser would be required is to compare the
visual output or how js behaves. That's where GD could help, to
compare screenshots of the rendered page. But that's not what we neeed
here.
That's what I was trying to explain.
Cheers,
--
Pierre
On Tue, Feb 2, 2010 at 7:37 AM, Venkat Raman Don
<don.ra...@microsoft.com> wrote:
> Hi,
>
> Let's don't argue just for the heck of it.
>
> Can I know why browser is not a good thing. And what solution you are
> arriving into. And can you help me share the coding for that solution if we
> find it better. And BTW my solution doesn't involve comparing screenshot.
>
> I think I have given enough reason why not to use GD/COM. Do you still think
> using COM/GD is a viable option? Or you have another alternative? I already
> told you we can use Mozilla based browser which can be used across platform.
> Ideally a solution should be scalable and work on different matrix.
>
> Thanks,
> Don.
>
> -----Original Message-----
> From: Pierre Joye [mailto:pierre....@gmail.com]
> Sent: Monday, February 01, 2010 1:04 PM
> To: Venkat Raman Don
> Cc: php-wind...@lists.php.net
> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>
> On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
> <don.ra...@microsoft.com> wrote:
>> Hi,
>>
>> A good idea about using COM/GD. Let's talk about some pro/cons of it and the
>> solution I gave.
>> 1. COM never worked with default IIS configuration because of permission
>> issues. This means again you are not simulating a real world scenario.
>> 2. COM based solution will never have the ability to be ported to UNIX world.
>> 3. GD can be used for screenshot comparison but any screenshot comparison
>> will have some error of margin. Plus your thing (expected output) will be
>> dependent on screen resolution/display settings etc. If your code has to be
>> portable going this route is not a good idea in my view.
>>
>> Regarding dependency on IE, I see no reason why we cannot use a Mozilla
>> based browser and automate it. That way it can work on any platform though
>> it will have its own challenges but not the ones we will face using GD and
>> COM.
>
> Sorry, I was not clear. My point was: There is no need of a browser to
> do http requests and compare the output.
>
> For test client side results (visuallly, js, etc.), there are
> excellent tools out there like selenium, but that's not what we
> discuss here.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--- End Message ---
--- Begin Message ---
On Tue, Feb 2, 2010 at 5:06 PM, Venkat Raman Don
<don.ra...@microsoft.com> wrote:
> Hi,
>
> Pierre, I understand that there are alternate ways. I was just asking why the
> browser way is bad or not acceptable? Or you are okay with browser way and
> suggesting an alternative. If you have concerns regarding using browser to
> test, I would like to know it as it also impacts WINCACHE quality overall.
>
Why are you using something what isn't needed? If you dont need the
rendered layout, executed client side js, then what are the advantages
using a browser over a php module?
Tyrael
> Thanks,
> Don.
>
> -----Original Message-----
> From: Pierre Joye [mailto:pierre....@gmail.com]
> Sent: Tuesday, February 02, 2010 1:21 AM
> To: Venkat Raman Don
> Cc: php-wind...@lists.php.net
> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>
> hi,
>
> Let me start from scratch:
>
> To test the output of a http request, no browser is required. PHP
> alone suffices, or wget/curl cmd line (or other similar tools). PHP
> supports HTTP (incl. headers), the diff can be generated easily, see
> run-tests.php.
>
> The only reason why a browser would be required is to compare the
> visual output or how js behaves. That's where GD could help, to
> compare screenshots of the rendered page. But that's not what we neeed
> here.
>
> That's what I was trying to explain.
>
> Cheers,
> --
> Pierre
>
> On Tue, Feb 2, 2010 at 7:37 AM, Venkat Raman Don
> <don.ra...@microsoft.com> wrote:
>> Hi,
>>
>> Let's don't argue just for the heck of it.
>>
>> Can I know why browser is not a good thing. And what solution you are
>> arriving into. And can you help me share the coding for that solution if we
>> find it better. And BTW my solution doesn't involve comparing screenshot.
>>
>> I think I have given enough reason why not to use GD/COM. Do you still think
>> using COM/GD is a viable option? Or you have another alternative? I already
>> told you we can use Mozilla based browser which can be used across platform.
>> Ideally a solution should be scalable and work on different matrix.
>>
>> Thanks,
>> Don.
>>
>> -----Original Message-----
>> From: Pierre Joye [mailto:pierre....@gmail.com]
>> Sent: Monday, February 01, 2010 1:04 PM
>> To: Venkat Raman Don
>> Cc: php-wind...@lists.php.net
>> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>>
>> On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
>> <don.ra...@microsoft.com> wrote:
>>> Hi,
>>>
>>> A good idea about using COM/GD. Let's talk about some pro/cons of it and
>>> the solution I gave.
>>> 1. COM never worked with default IIS configuration because of permission
>>> issues. This means again you are not simulating a real world scenario.
>>> 2. COM based solution will never have the ability to be ported to UNIX
>>> world.
>>> 3. GD can be used for screenshot comparison but any screenshot comparison
>>> will have some error of margin. Plus your thing (expected output) will be
>>> dependent on screen resolution/display settings etc. If your code has to be
>>> portable going this route is not a good idea in my view.
>>>
>>> Regarding dependency on IE, I see no reason why we cannot use a Mozilla
>>> based browser and automate it. That way it can work on any platform though
>>> it will have its own challenges but not the ones we will face using GD and
>>> COM.
>>
>> Sorry, I was not clear. My point was: There is no need of a browser to
>> do http requests and compare the output.
>>
>> For test client side results (visuallly, js, etc.), there are
>> excellent tools out there like selenium, but that's not what we
>> discuss here.
>>
>> Cheers,
>> --
>> Pierre
>>
>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>>
>> --
>> PHP Windows Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
>
>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hi,
The reason I am using browser is because I wanted to simulate the way server
works.
Thanks for all the input. I will look into other modules and see if a similar
thing can be achieved using PHP itself.
Don.
-----Original Message-----
From: Ferenc Kovacs [mailto:tyr...@gmail.com]
Sent: Tuesday, February 02, 2010 8:29 AM
To: Venkat Raman Don
Cc: Pierre Joye; php-wind...@lists.php.net
Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
On Tue, Feb 2, 2010 at 5:06 PM, Venkat Raman Don <don.ra...@microsoft.com>
wrote:
> Hi,
>
> Pierre, I understand that there are alternate ways. I was just asking why the
> browser way is bad or not acceptable? Or you are okay with browser way and
> suggesting an alternative. If you have concerns regarding using browser to
> test, I would like to know it as it also impacts WINCACHE quality overall.
>
Why are you using something what isn't needed? If you dont need the rendered
layout, executed client side js, then what are the advantages using a browser
over a php module?
Tyrael
> Thanks,
> Don.
>
> -----Original Message-----
> From: Pierre Joye [mailto:pierre....@gmail.com]
> Sent: Tuesday, February 02, 2010 1:21 AM
> To: Venkat Raman Don
> Cc: php-wind...@lists.php.net
> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>
> hi,
>
> Let me start from scratch:
>
> To test the output of a http request, no browser is required. PHP
> alone suffices, or wget/curl cmd line (or other similar tools). PHP
> supports HTTP (incl. headers), the diff can be generated easily, see
> run-tests.php.
>
> The only reason why a browser would be required is to compare the
> visual output or how js behaves. That's where GD could help, to
> compare screenshots of the rendered page. But that's not what we neeed
> here.
>
> That's what I was trying to explain.
>
> Cheers,
> --
> Pierre
>
> On Tue, Feb 2, 2010 at 7:37 AM, Venkat Raman Don
> <don.ra...@microsoft.com> wrote:
>> Hi,
>>
>> Let's don't argue just for the heck of it.
>>
>> Can I know why browser is not a good thing. And what solution you are
>> arriving into. And can you help me share the coding for that solution if we
>> find it better. And BTW my solution doesn't involve comparing screenshot.
>>
>> I think I have given enough reason why not to use GD/COM. Do you still think
>> using COM/GD is a viable option? Or you have another alternative? I already
>> told you we can use Mozilla based browser which can be used across platform.
>> Ideally a solution should be scalable and work on different matrix.
>>
>> Thanks,
>> Don.
>>
>> -----Original Message-----
>> From: Pierre Joye [mailto:pierre....@gmail.com]
>> Sent: Monday, February 01, 2010 1:04 PM
>> To: Venkat Raman Don
>> Cc: php-wind...@lists.php.net
>> Subject: Re: [PHP-WIN] A way available to test PHP CGI builds.
>>
>> On Mon, Feb 1, 2010 at 9:59 PM, Venkat Raman Don
>> <don.ra...@microsoft.com> wrote:
>>> Hi,
>>>
>>> A good idea about using COM/GD. Let's talk about some pro/cons of it and
>>> the solution I gave.
>>> 1. COM never worked with default IIS configuration because of permission
>>> issues. This means again you are not simulating a real world scenario.
>>> 2. COM based solution will never have the ability to be ported to UNIX
>>> world.
>>> 3. GD can be used for screenshot comparison but any screenshot comparison
>>> will have some error of margin. Plus your thing (expected output) will be
>>> dependent on screen resolution/display settings etc. If your code has to be
>>> portable going this route is not a good idea in my view.
>>>
>>> Regarding dependency on IE, I see no reason why we cannot use a Mozilla
>>> based browser and automate it. That way it can work on any platform though
>>> it will have its own challenges but not the ones we will face using GD and
>>> COM.
>>
>> Sorry, I was not clear. My point was: There is no need of a browser
>> to do http requests and compare the output.
>>
>> For test client side results (visuallly, js, etc.), there are
>> excellent tools out there like selenium, but that's not what we
>> discuss here.
>>
>> Cheers,
>> --
>> Pierre
>>
>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>>
>> --
>> PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit:
>> http://www.php.net/unsub.php
>>
>>
>>
>
>
>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
>
> --
> PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit:
> http://www.php.net/unsub.php
>
>
--
PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Hi,
On Tue, Feb 2, 2010 at 6:13 PM, Venkat Raman Don
<don.ra...@microsoft.com> wrote:
> Hi,
>
> The reason I am using browser is because I wanted to simulate the way server
> works.
I don't want to state the obvious but servers have no idea what is
actually doing the request, whether you use telnet, curl, wget or even
a browser, is irrelevent as long as the HTTP query is valid.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--- End Message ---
--- Begin Message ---
I need this for 5.3.1. Can you compile it for me? I've compiled PHP once
(we're using MS SQL Server Driver For PHP, had to compile for 5.3), but
I'm very shaky about it.
Keith Davis (214) 906-5183
-----Original Message-----
From: Pierre Joye [mailto:pierre....@gmail.com]
Sent: Saturday, January 30, 2010 12:28 PM
To: Robert
Cc: php-wind...@lists.php.net
Subject: Re: [PHP-WIN] What about php 5.3 and printers or
PHP_PRINTER.DLL ?
hi,
On Sat, Jan 30, 2010 at 6:43 PM, Robert <effe....@virgilio.it> wrote:
> Is still possible to print from php scripts directly to server's
> attached printers?
> (here it is php for windows, so this question is intended as to print
> on a windows server WAMP)
>
> Thank you for any update.
>
> A related curiosity is about PHP_PRINTER.DLL. Has that dll been
abandoned?
>
> Mr. Pierre Joye is publishing one intended (seems) to fit on php 5.2.8
> http://downloads.php.net/pierre/
Pierre works too ;)
> but using it with last apache makes that extension to not be loaded
> (checked on apache error log). So playing with search engines i've
> found (looks like) that the higher php version usable with
> php_printer.dll is
>
> PHP 5.2.8 with pecl for PHP 5.2.6
> http://us2.php.net/get/pecl-5.2.6-Win32.zip/from/a/mirror
>
> it does work, already verified.
It should work with 5.2.6 and later.
> Yes, cool! ... But the behaviour is that this does not allow me to
> upgrade MySQL. (* see at bottom)
> "Your PHP MySQL library version 5.0.51a differs from your MySQL server
> version 5.1.xx. This may cause unpredictable behavior"
It should work just fine.
> Thank you for any help or tip on how to upgrade PHP and still be able
> to print directly to server's attached printers from php scripts.
Do you need printer for 5.3? I did not try to compile it lately but it
should be possible.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Windows Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
This message (including any attachments) may contain confidential or otherwise
privileged information and is intended only for the individual(s) to which it
is addressed. If you are not the named addressee you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately by e-mail
if you have received this e-mail by mistake and delete this e-mail from your
system. E-mail transmission cannot be guaranteed to be secured or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses. The sender therefore does not accept liability
for any errors or omissions in the contents of this message or that arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version from the sender.
www.pridedallas.com
--- End Message ---
