On Sun, 14 Aug 2005, George Schlossnagle wrote:
On Aug 14, 2005, at 3:37 PM, Jani Taskinen wrote:
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricte
Andrei,
it was controlled by an ini setting. there are certain APIs that take or
return offsets, so translation
was done in those instances depending on the setting. Here's an example
(it's not currently implemented
this way, though..) since my concern was only the extension, i didnt touch
the
And this was controlled how and from where?
-Andrei
On Aug 14, 2005, at 12:29 PM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
Back in the early days of the extension, i had a request global
ICUG(codepoint_semantics) which controlled this. Setting this to
false would
revert to code-un
Back in the early days of the extension, i had a request global
ICUG(codepoint_semantics) which controlled this. Setting this to false would
revert to code-unit indexing (which ICU does internally).
clayton
"Andrei Zmievski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Then
Let's keep it pleasant, please.
-Andrei
On Aug 14, 2005, at 1:16 PM, Jani Taskinen wrote:
On Sun, 14 Aug 2005, Zeev Suraski wrote:
worried about the wholesale mode that internals@ switched into,
the almost unanimous "YES!" response, and the overall feeling that
suddenly with 6.0
Then why don't we put our collective brains together and think of a
solution for this that does not involve hacks?
-Andrei
On Aug 14, 2005, at 3:51 AM, Derick Rethans wrote:
In quite some cases for me i'm sure there are no surrogates in the
text
I'm parsing. Having to deal with rescanni
Then we should fix one or the other.
-Andrei
On Aug 14, 2005, at 3:47 AM, Derick Rethans wrote:
Might be true, but the manual lists this for years already:
http://www.php.net/manual/en/
language.types.string.php#language.types.string.parsing.complex
Derick
--
Derick Rethans
http://derick
http://icu.sourceforge.net/apiref/icu4c/ustdio_8h.html#a36
-Andrei
On Aug 14, 2005, at 6:34 AM, Derick Rethans wrote:
Hei,
currently I've the following [pseudo] code:
c = "";
a = snprintf(buffer, 32, "%0d", day);
b = snprintf(buffer, 32, "%s", daynames[dayofweek]);
smartstr
Translating the documentation,I am a chinese,I want to joint into the doc team
of chese phpdoc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
i dont consistently agree with Zeev's opinions, but what was that for ???
l0t3k
"Jani Taskinen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sun, 14 Aug 2005, Zeev Suraski wrote:
>
>> worried about the wholesale mode that internals@ switched into, the
>> almost unanimous "YES
On 8/14/05, George Schlossnagle <[EMAIL PROTECTED]> wrote:
>
> On Aug 14, 2005, at 3:37 PM, Jani Taskinen wrote:
>
> > On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
> >
> >
> >> If apc comes bundled then it includes apc_store() and apc_fetch()
> >> this
> >> is pretty much $_MEMORY with a few twea
On Aug 14, 2005, at 3:37 PM, Jani Taskinen wrote:
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
If apc comes bundled then it includes apc_store() and apc_fetch()
this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
I need such a
Marc Richards wrote:
Rasmus Lerdorf wrote:
Jani Taskinen wrote:
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
Shmop does just that, it takes a string of data (any data) and puts it
in memory. Serialization is something sysvshm extension does.
Ilia
Guillaume Ponçon wrote:
> It's true. I know shmop, but the ideal would be to be able to store
> large persistent variables in memory without serialization ope
It's true. I know shmop, but the ideal would be to be able to store
large persistent variables in memory without serialization operations
(without deserialization with each reading).
Thanks for these informations.
Guillaume
Ilia Alshanetsky wrote:
If you just want memory access PHP already
Rasmus Lerdorf wrote:
Jani Taskinen wrote:
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
I need such a 'global se
Jani Taskinen wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
I need such a 'global session' that is available with multiple
front-end servers..ie. usin
If you just want memory access PHP already offers shmop extension for
raw data storage and manipulation as well as sysvshm for storing
serialized variables.
Ilia
Guillaume Ponçon wrote:
> Ondrej Ivanič wrote:
>
>>>
>>> pecl/apc has apc_store/apc_fetch:
>>>
>>> http://livedocs.phpdoc.info/index.p
Ondrej Ivanič wrote:
pecl/apc has apc_store/apc_fetch:
http://livedocs.phpdoc.info/index.php?l=en&q=function.apc-store
I know about APC, but IMHO I can't use it. On webservers are Zend
Optimizer or mmcache (eAccelerator now) used.
But the approach is very interesting. The french java dev
Jani Taskinen wrote:
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
I need such a 'global session' that is availab
On Sun, 14 Aug 2005, Zeev Suraski wrote:
worried about the wholesale mode that internals@ switched into, the almost
unanimous "YES!" response, and the overall feeling that suddenly with 6.0
Good. Phear the masses. It's not your vote that counts anymore.
--Jani
--
PHP Internals - PHP
pecl/apc has apc_store/apc_fetch:
http://livedocs.phpdoc.info/index.php?l=en&q=function.apc-store
I know about APC, but IMHO I can't use it. On webservers are Zend
Optimizer or mmcache (eAccelerator now) used.
--
Ondrej Ivanic
([EMAIL PROTECTED])
--
PHP Internals - PHP Runtime Development
Jani Taskinen wrote:
> On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
>
>> If apc comes bundled then it includes apc_store() and apc_fetch() this
>> is pretty much $_MEMORY with a few tweaks.
>
>
> Yes, but that is restricted to one server installations.
> I need such a 'global session' th
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
I need such a 'global session' that is available with multiple
fro
Ondrej Ivanič wrote:
> Al Baker wrote:
>
>> An embedded opcode cache I think is also essential and the surrounding
>> $_MEMORY sounds perfect to me. All Java guys (yeah I know PHP != Java)
>> say PHP isn't ready for the enterprise because it can't share
>> information between processes other than
Al Baker wrote:
An embedded opcode cache I think is also essential and the surrounding
$_MEMORY sounds perfect to me. All Java guys (yeah I know PHP != Java)
say PHP isn't ready for the enterprise because it can't share
information between processes other than arcane sessions. Having PHP
become
[]s
One of the primary goal on the table is to >simplify< things as we go into
PHP6. This is the antithesis of simplification. Not gonna happen.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski wrote:
> If we are to do anything about register_globals, perhaps we can change
> the name of the directive to something else (e.g. unprotected_globals),
> and of course keep its default 0. Admins will have to make an informed
> decision to turn it on again, and we can speak against i
On Aug 14, 2005, at 1:24 PM, Al Baker wrote:
An embedded opcode cache I think is also essential and the surrounding
$_MEMORY sounds perfect to me. All Java guys (yeah I know PHP !=
Java)
say PHP isn't ready for the enterprise because it can't share
information between processes other than ar
> First of all, in general - I don't subscribe to the school of 'we broke
> something, why not break more'. With every feature we break, we reduce
> the
> chances of people upgrading, of legacy apps working, and we reduce the
> overall success chances of the new version. Compatibility breakup is
I agree with Ilia that removing these would help drastically reduce the
security holes present in PHP applications and generally improve the
image of PHP security. Or an alternative way to say that, is it would
reduce the FUD being slung at PHP from ignorant people saying PHP is a
security nightma
Hello,
PHP 5 was an evolution of php4, adding good OO things and some new
extensions.
PHP 5.1 is going a bit further and make the new engine more
efficient.
Both keep old and annoyed things we had in php4.
PHP 6.0 is not going to be realease in the next months or maybe
even not this year.
PHP5
On Aug 14, 2005, at 1:08 PM, Lukas Smith wrote:
As for removing register globals, a simple auto prepend will get
you register globals back, same goes for magic quotes. But moving
this stuff into userland will force people to take another hard
look at their code.
Also a good thing for PH
register_globals have been deprecated since 4.2 so any modern
application should no rely on them if not for security then at least for
compatibility. Removing register globals would probably halve (if not
more) the number of security exploits (seem to number in 10s per day if
securityfocus stats ar
Zeev Suraski wrote:
Even if we forget about the users, and only think about ourselves -
unless something drastic happens, we're going to look at supporting 4
major different versions simultaneously - 4.3/4.4, 5.0, 5.1 and 6.0. Is
it really such a great idea to start breaking compatibility bey
Aidan Lister wrote:
I think PHP 6.0 provides an excellent opportunity to rectify a huge number
of frustrating inconsistencies; it would be a shame not to make the most of
this.
The two biggest inconsistencies raised by users and "language comparison"
groups are a) function argument order, and
Hi,
>
> First of all, in general - I don't subscribe to the school of 'we broke
> something, why not break more'. With every feature we break, we reduce the
> chances of people upgrading, of legacy apps working, and we reduce the
> overall success chances of the new version. Compatibility break
At 20:48 12/08/2005, Rasmus Lerdorf wrote:
Since we are breaking a lot of stuff in 6.0, at least with
Unicode_semantics=On I am wondering if it may not be time to break some
more stuff and do a bit of spring cleaning. It would mean many apps
would need some work to work on PHP 6, but at the same
It occurred to me, while reading different parts of this thread, that if
the named parameter feature makes it in to PHP 6.0, there's a solution
for both sides of the parameter order argument.
1) yes, would be really nice to clean up the param order for two main
reasons: a) constant manual chec
Hei,
currently I've the following [pseudo] code:
c = "";
a = snprintf(buffer, 32, "%0d", day);
b = snprintf(buffer, 32, "%s", daynames[dayofweek]);
smartstr_appends(&c, a);
smartstr_appends(&c, b);
return c.c;
This snippet of code returns a legac
Aaron Wormus wrote:
> How about allowing mod_php6 to run alongside mod_php? Provide an easy
> way for the hosting people to provide PHP6 without breaking everything.
>
> Aaron
>
It's very good idea ;) 6.0 is a major release, so it can break many
things, and with mod_php6 it can not worring about
Hello Derick,
Sunday, August 14, 2005, 12:47:46 PM, you wrote:
> On Sat, 13 Aug 2005, Andrei Zmievski wrote:
>> On Aug 13, 2005, at 5:37 PM, Jani Taskinen wrote:
>>
>> > -Inf
>> >
>> > We're talking about cleaning up legacy stuff, not creating new, aren't
>> > we? :)
>> > And iirc,
On Sat, 13 Aug 2005, Andrei Zmievski wrote:
> So, you'd rather have PHP users gain some speed at the expense of having to
> check for surrogates everywhere?
In quite some cases for me i'm sure there are no surrogates in the text
I'm parsing. Having to deal with rescanning the string for every
a
On Sat, 13 Aug 2005, Andrei Zmievski wrote:
> On Aug 13, 2005, at 5:37 PM, Jani Taskinen wrote:
>
> > -Inf
> >
> > We're talking about cleaning up legacy stuff, not creating new, aren't
> > we? :)
> > And iirc, using [] for strings has been "deprecated" for ages now.
>
> Not really.
On Sat, 13 Aug 2005, Sara Golemon wrote:
> > > set short_open_tags to off in any sample php.ini we ship.
> >
> > Ah yes, that reminds me:
> >
> > 17. Nuke every "alternative" open tag and only have >
> Agreed (though not so much nuke as default to off).
>
> Whenever open tags comes up, I
On Sat, 13 Aug 2005, Marcus Boerger wrote:
> Hello Derick,
>
> Saturday, August 13, 2005, 2:17:52 PM, you wrote:
>
> > On Fri, 12 Aug 2005, Sara Golemon wrote:
>
> >> > 7. Make identifiers case-sensitive
> >> >
> >> Or perhaps optionally case sensitive? I dunno, I've made my peace with PHP
> >
On Sat, 13 Aug 2005, Joseph Crawford wrote:
> what if i wanted to make sure it was a String, Integer, Boolean, Float,
> etc.. i would like to see that added to the type hinting ;)
This is not going to happen. We've discussed this plenty of times
before.
Derick
--
PHP Internals - PHP Runtime
Rasmus Lerdorf wrote:
Since we are breaking a lot of stuff in 6.0, at least with
Unicode_semantics=On I am wondering if it may not be time to break some
more stuff and do a bit of spring cleaning. It would mean many apps
would need some work to work on PHP 6, but at the same time I think it
is
48 matches
Mail list logo
