Re: [PHP-DEV] Of string constants, bytecode, and concatenation

[Daniel Cowgill]

On Wed, 26 Feb 2003, David Brown wrote:

> Okay. Makes complete sense. I was thinking more along the lines of
> "wouldn't it be nice if...?". I hadn't quite made it to "where would
> that belong?". :)
> 
> I'll check out the optimizers. I noticed that the new CVS version of APC
> seems to have a configuration option for optimization as well, though
> I'm not sure how far along it is.

That configuration option doesn't do anything right now (see the INSTALL file
for details)--the plan is to integrate the PEAR optimizer with APC (since
having separate extensions isn't particularly user-friendly), but I've been
too busy to get to it. It's on the to-do list...




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

[PHP-DEV] CVS Account Request: dcowgill

[Daniel Cowgill]

Maintain apc, apd and optimizer in PECL

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

Re: [PHP-DEV] Zend fast cache

[Daniel Cowgill]

On Saturday, November 30, 2002, at 07:17 PM, Sterling Hughes wrote:


The problem I see with an array approach from an api perspective is 
simply when a bucket
is free'd, in order to have efficient memory usage, we'd need a second 
level array scan
for every ALLOC_ZVAL().

Perhaps a linked list would be a better choice for this, as we can 
just be smart about bucket
access, and eliminate the need for a scan (could be possible I'm 
missing something?)

I agree, a singly linked list seems like a no-brainer; it's an ideal 
memory-pool data structure because inserts and deletes occur only at 
the front of the list (so they're constant-time), the links are free, 
and the implementation is straightforward.


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

[PHP-DEV] Re: [Zend Engine 2] RFC: Conversion patch

[Daniel Cowgill]

So why do the conversion in arithmetic? This seems bizarrely inconsistent to
me:



I think it's reasonable to expect those expressions to return the same value.


On Tue, 26 Nov 2002, Andi Gutmans wrote:

> http://marc.theaimsgroup.com/?l=php-dev&m=90279104406264&w=2
> 
> There's more...
> 
> Andi
> 
> At 10:21 PM 11/26/2002 +0100, Derick Rethans wrote:
> >On Tue, 26 Nov 2002, Andi Gutmans wrote:
> >
> > > I remember having a long conversation on this issue quite a long time ago.
> > > I think it was on php-dev. The bottom line was that we only want 
> > conversion
> > > in the scanner and not within PHP.
> >
> >Too bad, because the following thing is totally uninituitive:
> >
> >echo (int)"0x200";
> >
> >(prints "0")
> >
> >And I searched for a discussion on this, but couldnt' find it. I wonder
> >why it was decided to be like this.
> >
> >Derick
> >
> >--
> >
> >-
> >  Derick Rethans http://derickrethans.nl/
> >  JDI Media Solutions http://www.jdimedia.nl/
> >  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> >-
> 
> 



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

Re: [PHP-DEV] Programming question

[Daniel Cowgill]

> On Thu, Aug 02, 2001 at 12:24:03PM -0400, George Schlossnagle
> wrote:
> > On a related note, placing null-bytes in the middle of strings
> > (for example
> > in the names of the so-called lambda_functions generated from
> > create_function()) seems like a pretty questionable practice.
> 
> why, this makes sure that function-names generated by
> create_function() will never clash with userland code.
> i think that makes perfect sense.
> 
> tc

In that case, I should point out that

function __lambda_func() {}
$fn = create_function('', '');

does not work.

Dan



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: rand_str

[Daniel Cowgill]

This sort of function should be implemented in PHP. It doesn't say good
things about a language when such trivial functionality needs to be
implemented non-natively. And it doesn't need to be:

function str_rand($len = 8, $class = 'a..zA..Z0..9')
{
if (!preg_match_all('/(.)\.\.(.)/', $class, $matches)) {
return '';
}
$chars = array();
$m1 = $matches[1];
$m2 = $matches[2];
for ($i = 0; $i < count($m1); $i++) {
$chars = array_merge($chars,
range(ord($m1[$i]), ord($m2[$i])));
}
if (($nchars=count($chars)) == 0) {
return '';
}
else if ($nchars == 1) {
return str_pad('', $len, chr($chars[0]));
}
$str = '';
for ($i = 0; $i < $len; $i++) {
$str .= chr($chars[mt_rand(0, $nchars-1]);
}
return $str;
}

A translation into C might run about 100 times faster. In most applications,
that doesn't justify sacrificing the flexibility and safety of a native
implementation.

On a related note, I don't see why PHP shouldn't ship with a standard
library written in PHP.

-Dan

- Original Message -
From: "Cynic" <[EMAIL PROTECTED]>
To: "Jeroen van Wolffelaar" <[EMAIL PROTECTED]>
Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Sunday, August 05, 2001 5:16 PM
Subject: Re: [PHP-DEV] Re: rand_str


> At 22:50 8/5/2001, Jeroen van Wolffelaar wrote the following:
> --
> >> >Implementing something that has NOT that limitation, is far less
trivial.
> >>
> >> function str_rand($len = 8, $class = 'a-zA-Z1-9')
> >> {
> >> static $init = 1;
> >> if(1 == $init){
> >> mt_srand((double) microtime() * 100);
> >> $init = 0;
> >> }
> >> $chars = array();
> >> for($i = 0; $i < $len; $i++){
> >> $chars[] = chr(mt_rand(0,255));
> >> }
> >> return implode('', preg_grep('|['.preg_quote($class).']|',$chars));
> >> }
> >>
> >> Just a little bit different syntax for the second argument.
> >> What's the big deal? :)
> >
> >Okay, but hey, you're a PHP-expert with probably many years of
experience...
>
> Fr from that. :)
>
> >By the way, your function won't return strings of length $len... ;)
>
> Oh, shit. Optimization instead of a function. :)
> I've been sitting before the CRT for 30 hours...
>
> >And you could say that preg_grep is quite a hack.
>
> Well, it nicely fits the bill - if you use the second argument as
> a character class, preg_quote/grep() lends itself. Or do you mean the
> concatenation? That's just a matter of formatting. Take it out of the
> preg_grep() call, and it'll look better.
>
> >Anyway, this didn't convince me it's trivial... I'm sorry.
>
> ok. :) seems like the only function that'll be missing from PHP
> will be write_the_app(); :)))
>
> But this is really a non-issue. I'm fine with or without str_rand(),
> I was just trying to show that it's pretty easy to write one in PHP,
> and so the function isn't really necessary. I know, there's nl2br()
> which _is_ simple, but that's backed by the fact that in a web-oriented
> language, _everybody_ would write their own nl2br(). This is not the
> case with str_rand()...
>
> And now help me down off that soap box. :)
>
>
>
>
> [EMAIL PROTECTED]
> -
> And the eyes of them both were opened and they saw that their files
> were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]