[PHP] actually HTML again; resizeing images

2013-03-17 Thread georg
Anyone knows a good reading about how and when images displayd with HTML tags 
are 
re-sized ?

tnx
georg

[PHP] Re: actually HTML again; resizeing images

2013-03-17 Thread Jim Giner

On 3/17/2013 9:22 AM, georg wrote:

Anyone knows a good reading about how and when images displayd with HTML tags 
are
re-sized ?

tnx
georg


not php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] actually HTML again; resizeing images

2013-03-17 Thread Stuart Dallas
On 17 Mar 2013, at 13:22, georg georg.chamb...@telia.com wrote:

 Anyone knows a good reading about how and when images displayd with HTML tags 
 are 
 re-sized ?

Not entirely sure what you mean, but a downloaded image will be resized when it 
needs to be shown in different dimensions to the actual image, whether that's 
due to width and height attributes on an img tag, or CSS styles, or whatever.

The specific algorithm used (which I'm guessing is what you mean by how is up 
to the browser and cannot be controlled.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] actually HTML again; resizeing images

2013-03-17 Thread David OBrien
On Mar 17, 2013 12:28 PM, Stuart Dallas stu...@3ft9.com wrote:

 On 17 Mar 2013, at 13:22, georg georg.chamb...@telia.com wrote:

  Anyone knows a good reading about how and when images displayd with
HTML tags are
  re-sized ?

 Not entirely sure what you mean, but a downloaded image will be resized
when it needs to be shown in different dimensions to the actual image,
whether that's due to width and height attributes on an img tag, or CSS
styles, or whatever.

 The specific algorithm used (which I'm guessing is what you mean by how
is up to the browser and cannot be controlled.

 -Stuart

 --
 Stuart Dallas
 3ft9 Ltd
 http://3ft9.com/

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php

Unless you use something like treesaver


Re: [PHP] variable type - conversion/checking

2013-03-17 Thread Maciek Sokolewicz

On 16-3-2013 19:20, Matijn Woudt wrote:

On Sat, Mar 16, 2013 at 6:52 PM, Maciek Sokolewicz 
maciek.sokolew...@gmail.com wrote:


Hi,


I have tried to find a way to check if a character string is possible to
test whether it is convertible to an intger !

any suggestion ?

BR georg



All responses in this thread have been very nice; but you could also try a
much simpler 2-step check:

1. is_numeric
2. if true  check if there's a decimal character in the string:

if(is_numeric($str)  false === strpos('.', $str)) {
// it's an int for sure
} else {
// might be a number, but it's definitly not an int

}



Wrong.  is_numeric will accept 1e1, which is a float, so you would need to
check for e or E too.

- Matijn

Although in theory I agree, indeed any e* number is treated as a 
floating point number. However, considering the exponent and the base 
are forced to be integer numbers (due to exclusion of decimal points), 
in the real number system, you will *always* end up with a natural 
number, i.e. integer. Regardless of your input.


So as a result, the input could always be interpreted as an integer, 
without any precision-loss using the method above.

- Tul

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP] modulo function

2013-03-17 Thread georg
Guess there should be one in PHP but cant find it 

(tnx for many earlier answers)

Br georg

[PHP] Re: modulo function

2013-03-17 Thread Maciek Sokolewicz

On 17-3-2013 22:23, georg wrote:

Guess there should be one in PHP but cant find it

(tnx for many earlier answers)

Br georg



You mean the modulus operator? 10%3 = 1
http://www.php.net/manual/en/language.operators.arithmetic.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] variable type - conversion/checking

2013-03-17 Thread Matijn Woudt
On Sun, Mar 17, 2013 at 10:20 PM, Maciek Sokolewicz 
maciek.sokolew...@gmail.com wrote:

 On 16-3-2013 19:20, Matijn Woudt wrote:

 On Sat, Mar 16, 2013 at 6:52 PM, Maciek Sokolewicz 
 maciek.sokolew...@gmail.com wrote:

  Hi,


 I have tried to find a way to check if a character string is possible to
 test whether it is convertible to an intger !

 any suggestion ?

 BR georg


 All responses in this thread have been very nice; but you could also try
 a
 much simpler 2-step check:

 1. is_numeric
 2. if true  check if there's a decimal character in the string:

 if(is_numeric($str)  false === strpos('.', $str)) {
 // it's an int for sure
 } else {
 // might be a number, but it's definitly not an int

 }


 Wrong.  is_numeric will accept 1e1, which is a float, so you would need to
 check for e or E too.

 - Matijn

  Although in theory I agree, indeed any e* number is treated as a
 floating point number. However, considering the exponent and the base are
 forced to be integer numbers (due to exclusion of decimal points), in the
 real number system, you will *always* end up with a natural number, i.e.
 integer. Regardless of your input.

 So as a result, the input could always be interpreted as an integer,
 without any precision-loss using the method above.
 - Tul


Except... that it might not fit in an 32 or 64 bit integer, which would
lead to precision loss.

- Matijn


[PHP] Re: [PHP-DEV] feature request : easy shared memory

2013-03-17 Thread Larry Garfield

On 03/14/2013 01:21 PM, Bob Weinand wrote:

Sharing active memory between processes goes against the shared nothing 
design of PHP.  The lack of the feature you're describing is itself a feature. :-)

If you had real shared memory, then you're now writing a multi-threaded app.  
Even if you aren't using threads per se it's the same level of potential for 
spooky action at a distance.  If your problem space really requires that (and 
there certainly are those that do), Java or NodeJs will suit you better because 
those are built specifically for a persistent-server model, rather than PHP's 
shared-nothing design. However, in practice most PHP/web applications don't 
need that, because HTTP is a stateless request/response system.  Shared-nothing 
more closely models what the actual environment is doing, and can still be very 
performant as long as you don't do anything naive.

If you're doing something stateful like Web Sockets, then you can run PHP as a 
cli application that is its own persistent server rather than as an Apache 
add-on.  For that, look at Ratchet: http://socketo.me/

--Larry Garfield

If PHP should be so restrictive against sharing, why are there extensions like 
memcached, ...? Someone must have missed this possibility to share rapidly...

If I need something like websockets, I use the pthreads extension: perfectly 
suited for stateful applications.

For example: I want to have the database in memory (no, no mysql Memory-tables; 
this is too slow...) and only do the updates into the database for faster 
access when most contents are read-only. What are these good reasons against 
such a feature except it violates the shares-nothing superlative of PHP. (Even 
if this feature would exist, you can still write PHP without sharing)

Bo Weinand


Memcache is out of process.  There are possible race conditions there, 
but FAR fewer and FAR more contained than true multi-threaded environments.


This list has debated the merits of shared-nothing many times before; it 
was a deliberate design decision in the interest of simplifying 
development for the overwhelming majority of users.  If your app is so 
performance sensitive that a memcache lookup is going to bring it to its 
knees, then either you're misusing PHP or you're better off using 
something other than PHP.  (PHP is not the tool for every use case.)


In any event, adding true shared memory to PHP would be nearly 
impossible without completely redesigning the way it interacts with web 
servers.  The alternative is to write your own PHP CLI application that 
connects to sockets itself and runs as a daemon (possibly using the 
pthreads extention as you mention), and cut apache/nginx out of the 
picture entirely.  If your use case calls for that, knock yourself out.  
But the good reasons against adding such a feature is that it would 
require rewriting everything and rearchitecting the entire Apache SAPI, 
which is not happening any time soon.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php