php-general Digest 6 Jul 2010 21:41:17 -0000 Issue 6833
Topics (messages 306702 through 306716):
Re: Question about the Board
306702 by: Gary .
306704 by: Ashley Sheridan
306710 by: Gary .
Re: "php -l" - does it find *anything*?
306703 by: Ashley Sheridan
306705 by: Peter Lind
306709 by: Gary .
306711 by: David Hutto
306712 by: Per Jessen
Re: Inner join woes... and sweet tea!
306706 by: Richard Quadling
cache_control_limiter
306707 by: Guus Ellenkamp
306708 by: Alexandre SIMON
Re: HTML in emails
306713 by: Andre Majorel
306714 by: Per Jessen
Re: how to use HTML Symbol Entities with mail() ?
306715 by: cr.vegelin.gmail.com
communication protocol
306716 by: Augusto Flavio
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
On 7/5/10, Gary[1] wrote:
> The last few times I have posted to the board, I recieved an email, which
> has the subject line of ???????? ??? ??? and is written in what appears to
> be greek
Ukrainian or Russian I would guess, looking at the headers.
> Anyone else have this happen?
Yes. Either some spammer harvesting addresses, or some **** setting up
filters on his email and getting it wrong.
[1] Another Gary, not this one :)
--- End Message ---
--- Begin Message ---
On Tue, 2010-07-06 at 11:00 +0200, Gary . wrote:
> On 7/5/10, Gary[1] wrote:
> > The last few times I have posted to the board, I recieved an email, which
> > has the subject line of ???????? ??? ??? and is written in what appears to
> > be greek
>
> Ukrainian or Russian I would guess, looking at the headers.
>
> > Anyone else have this happen?
>
> Yes. Either some spammer harvesting addresses, or some **** setting up
> filters on his email and getting it wrong.
>
>
> [1] Another Gary, not this one :)
>
I have had a couple such emails, requesting me to log in somewhere in
order to have my address 'validated' as non-spam, but I ignored it and
nothing bad has happened to me yet!
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On 7/6/10, Ashley Sheridan wrote:
> I have had a couple such emails, requesting me to log in somewhere in
> order to have my address 'validated' as non-spam, but I ignored it and
> nothing bad has happened to me yet!
Not yet.
*hides cattle prod behind back*
--- End Message ---
--- Begin Message ---
On Tue, 2010-07-06 at 10:54 +0200, Gary . wrote:
> Or, alternatively put, is there any way to find the kind of problems in
> foo2 & foo3 (below), at "*compile* time"?
>
> ,----[ lint-test.php ]
> | <?php
> |
> | error_reporting(E_ALL | E_STRICT);
> |
> | function foo1()
> | {
> | $bar = 'cheese';
> | echo $bar;
> | }
> |
> | function foo2()
> | {
> | $bar = 'cheese';
> | echo 'cheese';
> | }
> |
> | function foo3()
> | {
> | // $bar = 'cheese';
> | echo $bar;
> | }
> |
> | foo1();
> | foo2();
> | foo3();
> |
> | ?>
> `----
>
> I only get errors displayed when code happens to pass down the code
> path, i.e. at runtime:
> ,----
> | /home/jg/work $ php -l lint-test.php
> | No syntax errors detected in lint-test.php
> | /home/jg/work $ php lint-test.php
> | cheesecheese
> | Notice: Undefined variable: bar in
> | /home/jg/work/lint-test.php on line 20
> |
> | Call Stack:
> | 1.0000 61488 1. {main}()
> | /home/jg/work/lint-test.php:0
> | 1.0000 61680 2. foo3()
> | /home/jg/work/lint-test.php:25
> `----
>
> If foo3 never happens to be called when I am doing my testing (for
> example if the call is in some "if" branch that is never exercised) then
> it only gets found in production, so I would like to find this kind of
> thing using a static analyser. The kind of problem in foo2 I could live
> with, but would like to find as well, if possible. (Obviously I am using
> these two example problems as indicative of the type of things I want to
> find, it isn't an exhaustive list!)
>
> BTW, what problems *does* "php -l" pick up? I can't find a description
> anywhere.
>
According to the man page for php, the -l flag only checks the syntax,
so a warning wouldn't be displayed, as technically it's not a
show-stopper. Maybe some sort of unit testing would help pick out these
sorts of issues? As PHP isn't a compiled language, I guess it's harder
for it to pick up on things like this. You don't need to declare a
variable before using it in PHP like you do in a compiled language
(without getting into the murky territory of compiled PHP!) so some
things might only be picked up by unit testing.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On 6 July 2010 11:30, Ashley Sheridan <[email protected]> wrote:
> On Tue, 2010-07-06 at 10:54 +0200, Gary . wrote:
>
>> Or, alternatively put, is there any way to find the kind of problems in
>> foo2 & foo3 (below), at "*compile* time"?
>>
>> ,----[ lint-test.php ]
>> | <?php
>> |
>> | error_reporting(E_ALL | E_STRICT);
>> |
>> | function foo1()
>> | {
>> | $bar = 'cheese';
>> | echo $bar;
>> | }
>> |
>> | function foo2()
>> | {
>> | $bar = 'cheese';
>> | echo 'cheese';
>> | }
>> |
>> | function foo3()
>> | {
>> | // $bar = 'cheese';
>> | echo $bar;
>> | }
>> |
>> | foo1();
>> | foo2();
>> | foo3();
>> |
>> | ?>
>> `----
>>
>> I only get errors displayed when code happens to pass down the code
>> path, i.e. at runtime:
>> ,----
>> | /home/jg/work $ php -l lint-test.php
>> | No syntax errors detected in lint-test.php
>> | /home/jg/work $ php lint-test.php
>> | cheesecheese
>> | Notice: Undefined variable: bar in
>> | /home/jg/work/lint-test.php on line 20
>> |
>> | Call Stack:
>> | 1.0000 61488 1. {main}()
>> | /home/jg/work/lint-test.php:0
>> | 1.0000 61680 2. foo3()
>> | /home/jg/work/lint-test.php:25
>> `----
>>
>> If foo3 never happens to be called when I am doing my testing (for
>> example if the call is in some "if" branch that is never exercised) then
>> it only gets found in production, so I would like to find this kind of
>> thing using a static analyser. The kind of problem in foo2 I could live
>> with, but would like to find as well, if possible. (Obviously I am using
>> these two example problems as indicative of the type of things I want to
>> find, it isn't an exhaustive list!)
>>
>> BTW, what problems *does* "php -l" pick up? I can't find a description
>> anywhere.
>>
>
>
> According to the man page for php, the -l flag only checks the syntax,
> so a warning wouldn't be displayed, as technically it's not a
> show-stopper. Maybe some sort of unit testing would help pick out these
> sorts of issues? As PHP isn't a compiled language, I guess it's harder
> for it to pick up on things like this. You don't need to declare a
> variable before using it in PHP like you do in a compiled language
> (without getting into the murky territory of compiled PHP!) so some
> things might only be picked up by unit testing.
>
Yeah, unit testing is definitely the way to go, +1 on that idea.
Regards
Peter
--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
--- End Message ---
--- Begin Message ---
Ashley Sheridan writes:
> On Tue, 2010-07-06 at 10:54 +0200, Gary . wrote:
> If foo3 never happens to be called when I am doing my testing (for
> example if the call is in some "if" branch that is never exercised) then
> it only gets found in production, so I would like to find this kind of
> thing using a static analyser. The kind of problem in foo2 I could live
> with, but would like to find as well, if possible. (Obviously I am using
> these two example problems as indicative of the type of things I want to
> find, it isn't an exhaustive list!)
>
> BTW, what problems *does* "php -l" pick up? I can't find a description
> anywhere.
>
> According to the man page for php, the -l flag only checks the syntax, so a
> warning wouldn't be displayed, as technically it's not a show-stopper.
Well, I think foo3 is, but yeah, I know what you mean.
> Maybe
> some sort of unit testing would help pick out these sorts of issues?
I do. Actually I posted this by mistake to the phpunit mailing list
first :)
> As PHP
> isn't a compiled language, I guess it's harder for it to pick up on things
> like this.
Yeah. There are static checkers out there, even some FOSS ones. I guess
I'm just a bit frustrated that (as you say) the man page says that "-l"
checks syntax but doesn't really detail what kind of things that
covers. Actually, I can't even find a decent description of what
E_STRICT covers :( just that "Enabling E_STRICT during development has
some benefits. STRICT messages will help you to use the latest and
greatest suggested method of coding, for example warn you about using
deprecated functions."
"Some benefits"? "For example"? Telling people exactly what is covered
seems more useful, to me. Meh. Anyway, that's my whine over for the day
:)
--- End Message ---
--- Begin Message ---
On Tue, Jul 6, 2010 at 8:22 AM, Gary . <[email protected]> wrote:
> Ashley Sheridan writes:
>> On Tue, 2010-07-06 at 10:54 +0200, Gary . wrote:
>
>> If foo3 never happens to be called when I am doing my testing (for
>> example if the call is in some "if" branch that is never exercised) then
>> it only gets found in production, so I would like to find this kind of
>> thing using a static analyser. The kind of problem in foo2 I could live
>> with, but would like to find as well, if possible. (Obviously I am using
>> these two example problems as indicative of the type of things I want to
>> find, it isn't an exhaustive list!)
>>
>> BTW, what problems *does* "php -l" pick up? I can't find a description
>> anywhere.
>>
>> According to the man page for php, the -l flag only checks the syntax, so a
>> warning wouldn't be displayed, as technically it's not a show-stopper.
>
> Well, I think foo3 is, but yeah, I know what you mean.
>
>> Maybe
>> some sort of unit testing would help pick out these sorts of issues?
>
> I do. Actually I posted this by mistake to the phpunit mailing list
> first :)
>
>> As PHP
>> isn't a compiled language, I guess it's harder for it to pick up on things
>> like this.
>
> Yeah. There are static checkers out there, even some FOSS ones. I guess
> I'm just a bit frustrated that (as you say) the man page says that "-l"
> checks syntax but doesn't really detail what kind of things that
> covers. Actually, I can't even find a decent description of what
> E_STRICT covers :( just that "Enabling E_STRICT during development has
> some benefits.
Just to interject a little newbie talk... have you ever written a
program alone(something developers do for specific situations a lot I
find), and not properly written out the documentation because YOU
understood what you were doing, but were more into the code than
docking it?. This does seem to be a predominant theme amongst some
open source projects.
STRICT messages will help you to use the latest and
> greatest suggested method of coding, for example warn you about using
> deprecated functions."
>
> "Some benefits"? "For example"? Telling people exactly what is covered
> seems more useful, to me. Meh. Anyway, that's my whine over for the day
> :)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Gary . wrote:
> Yeah. There are static checkers out there, even some FOSS ones. I
> guess I'm just a bit frustrated that (as you say) the man page says
> that "-l" checks syntax but doesn't really detail what kind of things
> that covers.
It really is _only_ the syntax. Same goes for e.g. the C lint -
int main()
{
char *p;
p=0;
*p=0;
}
this is 100% syntactically correct, but will core dump if you run it.
--
Per Jessen, Zürich (24.2°C)
--- End Message ---
--- Begin Message ---
On 5 July 2010 17:27, Gary <[email protected]> wrote:
>
> "Richard Quadling" <[email protected]> wrote in message
> news:[email protected]...
>> On 5 July 2010 14:48, Pete Ford <[email protected]> wrote:
>>>> P.S. I don't have an emu.
>>>
>>> Clearly, or you'd know that they can't fly either...
>>> :)
>>
>> GIGO!!!
>
>
> Does that mean you do have a deathwatch beetle?
>
> Gary
No. It doesn't mean I've got a deathwatch beetle.
That would be a fallacious assumption
--- End Message ---
--- Begin Message ---
I'm trying to set the cache_control_limiter to public, but it seems to stay
in nocache. What can be wrong? Tried two servers.
--- End Message ---
--- Begin Message ---
If you want to manipulate cache control on PHP side, you must set PHP
directive "session.cache_limiter" to an empty value. Be then sure to always
set cache control headers to the right value according what your scripts do.
2010/7/6 Guus Ellenkamp <[email protected]>
> I'm trying to set the cache_control_limiter to public, but it seems to stay
> in nocache. What can be wrong? Tried two servers.
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
SIMON Alexandre
--- End Message ---
--- Begin Message ---
On 2010-07-04 11:43 -0400, Al wrote:
> Seems like, from my preliminary Google searching, I should not waste
> time with the standard's way and just go straight to sending simple
> html pages since all modern browsers handle it well. And, it appears
> to be the way web is going.
"Browsers" ? "The web" ? I thought it was about email ?
If it's HTML, I have to decode and save the email to a file from
my MUA and then switch a browser to read it. As you can imagine, I
rarely bother.
> It use to be that we specified content-type text/html, etc. and sent
> both the plain ASCII and the html with boundaries and so forth.
That is the only sane approach.
--
André Majorel http://www.teaser.fr/~amajorel/
--- End Message ---
--- Begin Message ---
Paul M Foster wrote:
> Here is the real problem with HTML email. Any straight text message
> will swell to many times its size when you HTML-ize it. Okay, so now
> you're sending the message around the internet to perhaps hundreds or
> thousands of users, using up many times the bandwidth that the actual
> message really needs. It's like installing a 100w light bulb when a
> 60w will do. There's simply no reason to suck CPU cycles all over the
> internet just to make your message "prettier".
In principle, I agree - in practice, CPU cycles are getting cheaper by
the minute, and being wasted all the time. Not using HTML is highly
unlikely to have a measurable impact on anybodys CPU cycles.
Besides, HTML is not just about making the message prettier. A number
of times I have experienced that important system notifications (from
our systems to customers') were simply ignored, apparently due to being
plain text. We decided to "jazz them up" a bit, and it worked.
--
Per Jessen, Zürich (25.6°C)
--- End Message ---
--- Begin Message ---
From: Ashley Sheridan
To: Manuel Lemos
Cc: [email protected] ; [email protected]
Sent: Saturday, July 03, 2010 1:22 PM
Subject: Re: [PHP] Re: how to use HTML Symbol Entities with mail() ?
On Fri, 2010-07-02 at 22:58 -0300, Manuel Lemos wrote:
Hello,
on 07/01/2010 10:34 AM [email protected] said the following:
> Hi List,
>
> I am working on generated emails, using the mail() function.
> Works fine, but when including characters like ∧ (= ∧) or ∨ (=
> ∨)
> in the message, these characters are displayed as ? in the emails.
>
> Snippet:
> $headers = 'MIME-Version: 1.0' . "\r\n";
> $headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
> ...
> $bool = mail ($mailto, $subject, $body, $headers);
>
> also tested with:
> $headers .= 'Content-type: text/html; charset=UTF-8' . "\r\n";
> but without result.
>
> Any ideas ?
> TIA, Cor
When those characters appear as question marks is because you are using
a font in the messages that does not have characters with those codes.
Try including the sections of those characters with some span tags like
this <span style="font-family: font-name-here">∨</span>
--
Regards,
Manuel Lemos
Find and post PHP jobs
http://www.phpclasses.org/jobs/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
I don't believe it is the font issue, and don't forget that outputting HTML
for an email is very different, so there are some things that you can specify
that will be ignored by some email clients when they render your email.
Those glyphs should be available to any system, as the email client should
use whatever font on the system is set up for the extended glyphs where they
are not available in the current font. What email clients are you testing this
on? Are they web based, or local? It's a good idea to test HTML emails on a
variety of email clients, as they all can behave very differently.
Thanks,
Ash
http://www.ashleysheridan.co.uk
Sorry for the delay; was away a few days.
The special characters (∧ ∨) are part of <td> tags.
I tested both:
<td><span style="font-family: arial,courier,times">∨</span></td>
and
<td style="font-family: arial,courier,times">∨</td>
but without the desired result.
BTW, I wrote that the spec. characters are displayed in my email as ?
In fact they are displayed as little squares, but copying it here makes it a ?
mark.
I am testing the HTML emails web based with Outlook Express,
with the Format - Encoding setting to UTF-8.
The only reason to use the spec. chars is to simulate arrows, without <img>.
TIA, Cor
--- End Message ---
--- Begin Message ---
Hi List,
I'm looking for a chat support likes the livezilla. The livezilla is a great
tool but doesn't have language supports to another language instead english
and german (operator side). Then I thought that a good option would be
develop my own chat support.
A great solution is build the server side in PHP. The client side would be
developed in PHP. For the operator side I thought that could be a Desktop
Windows Application build using the Flex.
I found that have a communication tool called BlazeDS for Flex that works
and helps with the development of this chat support. But the BlazeDS is for
Flex/Java. Is there some tool in PHP that helps the development of a server
web messaging likes the BlazeDS?
Thanks for all.
Augusto Morais
--- End Message ---
