[PHP-DEV] Re: Bug 61272
On 25 November 2012 11:58, Casper Langemeijer langemei...@php.net wrote: Hi all, Somewhere in May this year I discovered that our software would not run on PHP 5.4 because of changed behaviour of ob_start(). I discovered a bugreport that was marked 'Not a bug', but valuable info was already added to it. I contacted Michael Wallner (mike) directly because he marked the bug 'not a bug'. No response. I'm sorry that the new output control layer causes you such headaches. IIRC, 6 years back, when I implemented the new output control functionality, I kindly asked the list, whether to rather implement what's documented, or what the old code did, but I have yet been unable to find according mails. It pretty well may have been the case that the old code passed the output buffer contents through the handler prior discarding, but as it had not been documented (and I obviously failed to figure out a use case) I apparently implemented the more efficient way it currently is. No offense, no excuse, just a try to figure out what happened... -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DateTime::modify('now') is ignored, why?
Hi internals,
I would to modify a \DateTime object to the current time, thus I wrote this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation
(http://php.net/datetime.formats.relative) says: “Now - this is simply
ignored”. Really? But the behavior is pretty straightforward isn't?
“modify to now” means “set to the current date and time and let the
timezone unchanged”.
Thoughts?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
Hi Ivan,
$d = new \DateTime('+1 hour', new \DateTimeZone('Europe/Amsterdam'));
Is exactly the same as:
// Current timestamp with timezone
$d = new \DateTime(null, new \DateTimeZone('Europe/Amsterdam'));
// Add 1 hour to the timestamp with timezone
$d-modify('+1 hour');
This is what you would like to do right? As modifying the timestamp with
another timestamp would make no sense to me.
Kind regards,
Chris van Dam
Op 26-11-12 12:06 schreef Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net:
Hi internals,
I would to modify a \DateTime object to the current time, thus I wrote
this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation
(http://php.net/datetime.formats.relative) says: ³Now - this is simply
ignored². Really? But the behavior is pretty straightforward isn't?
³modify to now² means ³set to the current date and time and let the
timezone unchanged².
Thoughts?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
E-mail disclaimer Nederlands
De informatie verzonden met dit e-mailbericht is vertrouwelijk en kan wettelijk
voorbehouden zijn. Het is uitsluitend bestemd voor de geadresseerde. Gebruik
van deze informatie door anderen dan de geadresseerde en zij die gerechtigd
zijn daarvan kennis te nemen is verboden. Trace staat niet in voor de juiste en
volledige overbrenging van de inhoud van een verzonden e-mail, noch voor
tijdige ontvangst daarvan.
E-mail disclaimer English
The information contained in this communication is confidential and may be
legally privileged. It is intended solely for the use of the individual or
entity to whom it is addressed and others authorized to receive it. The use of
it by others is prohibited. Trace is neither liable for the proper and complete
transmission of the information contained in this communication nor for any
delay in its receipt.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
2012/11/26 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
Hi internals,
I would to modify a \DateTime object to the current time, thus I wrote
this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation (http://php.net/datetime.*
*formats.relative http://php.net/datetime.formats.relative) says: “Now
- this is simply ignored”. Really? But the behavior is pretty
straightforward isn't? “modify to now” means “set to the current date and
time and let the timezone unchanged”.
It's not like modify to something, but modify _with_ something. With
your point of view modifiy('+7 days') will _always_ point to next week,
but it should (and it's intuitive right), that it will point to 7 days
after the previous date. So what should modify with now mean?
Other way round: You are looking for the set*()-methods :) Because you
want to _set_ a date, not modify one.
Regards,
Sebastian
Thoughts?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
github.com/KingCrunch
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
Hi Chris,
You didn't understand. I have a \DateTime object, and I would like to
change the date and time to the current date and time = now.
Imagine you have a \DateTime object that was serialized and you would
like to “refresh” it, you need to $d-modify('now'). This is strictly
equivalent to $d-setTimestamp(time()) but in a more elegant way. But
the documentation says that “now” is ignored, and I would like to know
why because it is useful.
Thanks.
On 26/11/12 12:23, Chris van Dam wrote:
Hi Ivan,
$d = new \DateTime('+1 hour', new \DateTimeZone('Europe/Amsterdam'));
Is exactly the same as:
// Current timestamp with timezone
$d = new \DateTime(null, new \DateTimeZone('Europe/Amsterdam'));
// Add 1 hour to the timestamp with timezone
$d-modify('+1 hour');
This is what you would like to do right? As modifying the timestamp with
another timestamp would make no sense to me.
Kind regards,
Chris van Dam
Op 26-11-12 12:06 schreef Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net:
Hi internals,
I would to modify a \DateTime object to the current time, thus I wrote
this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation
(http://php.net/datetime.formats.relative) says: ³Now - this is simply
ignored². Really? But the behavior is pretty straightforward isn't?
³modify to now² means ³set to the current date and time and let the
timezone unchanged².
Thoughts?
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
E-mail disclaimer Nederlands
De informatie verzonden met dit e-mailbericht is vertrouwelijk en kan wettelijk
voorbehouden zijn. Het is uitsluitend bestemd voor de geadresseerde. Gebruik
van deze informatie door anderen dan de geadresseerde en zij die gerechtigd
zijn daarvan kennis te nemen is verboden. Trace staat niet in voor de juiste en
volledige overbrenging van de inhoud van een verzonden e-mail, noch voor
tijdige ontvangst daarvan.
E-mail disclaimer English
The information contained in this communication is confidential and may be
legally privileged. It is intended solely for the use of the individual or
entity to whom it is addressed and others authorized to receive it. The use of
it by others is prohibited. Trace is neither liable for the proper and complete
transmission of the information contained in this communication nor for any
delay in its receipt.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
Hi Sebastien,
On 26/11/12 12:25, Sebastian Krebs wrote:
2012/11/26 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
Hi internals,
I would to modify a \DateTime object to the current time, thus I wrote
this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation (http://php.net/datetime.*
*formats.relative http://php.net/datetime.formats.relative) says: “Now
- this is simply ignored”. Really? But the behavior is pretty
straightforward isn't? “modify to now” means “set to the current date and
time and let the timezone unchanged”.
It's not like modify to something, but modify _with_ something. With
your point of view modifiy('+7 days') will _always_ point to next week,
but it should (and it's intuitive right), that it will point to 7 days
after the previous date. So what should modify with now mean?
I understand the different, but then, why “now” is declared in the
documentation :-) ?
Other way round: You are looking for the set*()-methods :) Because you
want to _set_ a date, not modify one.
Exactly, setTimestamp(time()) resolved by problem.
Best regards.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
On Mon, 26 Nov 2012, Ivan Enderlin @ Hoa wrote:
On 26/11/12 12:25, Sebastian Krebs wrote:
2012/11/26 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
I would to modify a \DateTime object to the current time, thus I wrote
this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation (http://php.net/datetime.*
*formats.relative http://php.net/datetime.formats.relative) says: “Now
- this is simply ignored”. Really? But the behavior is pretty
straightforward isn't? “modify to now” means “set to the current date and
time and let the timezone unchanged”.
It's not like modify to something, but modify _with_ something. With
your point of view modifiy('+7 days') will _always_ point to next week,
but it should (and it's intuitive right), that it will point to 7 days
after the previous date. So what should modify with now mean?
I understand the different, but then, why “now” is declared in the
documentation :-) ?
Because people (like you) have tried it before and found it to not do as
they thought :-)
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
On 26/11/12 13:02, Derick Rethans wrote:
On Mon, 26 Nov 2012, Ivan Enderlin @ Hoa wrote:
On 26/11/12 12:25, Sebastian Krebs wrote:
2012/11/26 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
I would to modify a \DateTime object to the current time, thus I wrote
this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation (http://php.net/datetime.*
*formats.relative http://php.net/datetime.formats.relative) says: Now
- this is simply ignored. Really? But the behavior is pretty
straightforward isn't? modify to now means set to the current date and
time and let the timezone unchanged.
It's not like modify to something, but modify _with_ something. With
your point of view modifiy('+7 days') will _always_ point to next week,
but it should (and it's intuitive right), that it will point to 7 days
after the previous date. So what should modify with now mean?
I understand the different, but then, why now is declared in the
documentation :-) ?
Because people (like you) have tried it before and found it to not do as
they thought :-)
It would have been better never write this keyword ;-).
Thanks.
Have a good day.
PS: In the french version of the documentation, the it is ignored was
missing. I have submitted a patch.
--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/
PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
On Mon, 26 Nov 2012 15:06:09 +0400, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi internals,
I would to modify a \DateTime object to the current time, thus I wrote
this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation
(http://php.net/datetime.formats.relative) says: “Now - this is simply
ignored”. Really? But the behavior is pretty straightforward isn't?
“modify to now” means “set to the current date and time and let the
timezone unchanged”.
Thoughts?
Best regards.
Shouldn't DateTime be immutable? What's the point of DateTime object being
mutable?
I would include my point about why DateTime should be immutable but I even
can't come with any points except OO-logic and all I can say is I just
feel like mutable DateTime is wrong. What you think about it?
PS I'm not Nikita Popov (aka nikic) :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime::modify('now') is ignored, why?
On Mon, 26 Nov 2012, Nikita Nefedov wrote:
On Mon, 26 Nov 2012 15:06:09 +0400, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
I would to modify a \DateTime object to the current time, thus I
wrote this:
$d = new \DateTime('+1 hour');
$d-modify('now');
It did not work. Why? Because the documentation
(http://php.net/datetime.formats.relative) says: “Now - this is
simply ignored”. Really? But the behavior is pretty straightforward
isn't? “modify to now” means “set to the current date and time and
let the timezone unchanged”.
Shouldn't DateTime be immutable? What's the point of DateTime object
being mutable? I would include my point about why DateTime should be
immutable but I even can't come with any points except OO-logic and
all I can say is I just feel like mutable DateTime is wrong. What you
think about it?
Yes, it should have been immutable. Biggest mistake that I made in this
API. We can't change it anymore though.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug 61272
On 11/26/2012 10:19 AM, Michael Wallner wrote: I'm sorry that the new output control layer causes you such headaches. IIRC, 6 years back, when I implemented the new output control functionality, I kindly asked the list, whether to rather implement what's documented, or what the old code did, but I have yet been unable to find according mails. And now this code hits production for the first time I assume, if this is the only issue I think you have done a fab job! It pretty well may have been the case that the old code passed the output buffer contents through the handler prior discarding, but as it had not been documented (and I obviously failed to figure out a use case) I apparently implemented the more efficient way it currently is. Hmm.. I suppose It's up to me to make a strong (if possible watertight) plea for the old way. I will try: 1. I don't think my patch impacts the efficiency of php_output_clean(). It adds a single if with a binary compare. True: this causes output to get piped through the output handler, but the output handler callback function could be smart enough to back off when the PHP_OUTPUT_HANDLER_CLEAN bit is set in the second parameter of the callback. 2. Current behaviour is *not* according the documentation. ob_start() documentation states: An optional output_callback function may be specified. This function takes a string as a parameter and should return a string. The function will be called when the output buffer is flushed (sent) or **cleaned** (with ob_flush(), ob_clean() or similar function) or when the output buffer is flushed to the browser at the end of the request. When output_callback is called, it will receive the contents of the output buffer as its parameter and is expected to return a new output buffer as a result, which will be sent to the browser. (*-emphasis mine) Current behaviour differs: On calling ob_end_clean() or ob_clean(), output_callback is called, but *without* the contents of the output buffer as its parameter. 3. Implementing my patch will never break anything. The output will be passed to the callback, but anything returned by it *will* be discarded. 4. If you are not going to pass the contents of the output buffer on ob_end_clean() or ob_clean() to the callback function, Why would you call the callback anyway? You may think this is a weird feature, this is how we use it: In output_callback we assign the output we catch with output buffering to a string variable, and we use that later on in the request to build our output. Greetings, Casper
[PHP-DEV] Re: [VOTE] [RFC] ICU UConverter implementation for ext/intl
It's been a few weeks since voting opened and it's unanimous so far. If no one objects I'll plan on pushing into git on Friday. On Mon, Nov 5, 2012 at 9:26 AM, Sara Golemon poll...@php.net wrote: The requisite one week minimum has passed and there have been no further comments since my last update (which addressed all comments thereto) so I'm opening the voting process on https://wiki.php.net/rfc/uconverter Cheers, -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Modify tempnam() to handle directories and auto-cleanup
https://wiki.php.net/rfc/request-tempnam Just a bit of hand-holding for those who don't remember to clean up their messes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Modify tempnam() to handle directories and auto-cleanup
Hi, On Mon, 2012-11-26 at 13:21 -0800, Sara Golemon wrote: https://wiki.php.net/rfc/request-tempnam Just a bit of hand-holding for those who don't remember to clean up their messes. An obvious question is: When in shutdown should that be called? Assume I have a session handler which uses such a temporary directory which is backed by a custom stream while having a registered shutdown function accessing that session (what did i forget to put into that scenario?) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Modify tempnam() to handle directories and auto-cleanup
An obvious question is: When in shutdown should that be called? Assume I have a session handler which uses such a temporary directory which is backed by a custom stream while having a registered shutdown function accessing that session (what did i forget to put into that scenario?) Is this custom session handler wanting the temporary directory to last between requests? If so then they'd just not use the TEMPNAM_REQUEST flag. If not, then there wouldn't be a problem since RSHUTDOWN happens after calling the methods registered with register_shutdown_function(). -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HHVM and PHP
On 11/26/2012 05:24 PM, Raymond Irving wrote: Hello, I've being reading about HHVM and the numbers are looking great but I was just wondering if we will we ever see something like HHVM being added to the PHP core? No, not likely. Maybe an LLVM-based JIT one day, but the HHVM approach is not something any of us are looking at. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HHVM and PHP
I've being reading about HHVM and the numbers are looking great but I was just wondering if we will we ever see something like HHVM being added to the PHP core? No, not likely. Maybe an LLVM-based JIT one day, but the HHVM approach is not something any of us are looking at. To echo Rasmus' reply: No. HHVM is a reimplementation of the PHP language from the ground up, so logically speaking adding it to the PHP core doesn't actually make sense. They're different birds from the get-go. PHP could adopt a similar strategy of translating bytecode to native machine code (again echoing Rasmus' reply), but that would be a large undertaking by itself, and adapting zval unions to static type analysis is a whole other layer of complexity beyond that. The important thing to keep in mind is what each implementation is good at, and what it's not. As the maintainer of the OSS version of HipHop (HHVM), I'll be the first to admit that the official PHP engine and runtime have a broader range of platform/architecture support, and stronger community, and a larger library of extensions and functionality behind it. Also, because of it's lifecycle design, PHP outperforms HHVM on single-run command-line scripts. On the other hand, HHVM does outperform Apache+PHP for web requests quite well. Facebook would need at least 5x as many web-servers (and we use a lot as it is) if we were using normal PHP. That's not to say PHP isn't fast, but interpreted bytecode using loose typing will never keep pace with native machine code and strict typing. Standard Disclaimer: Yes, front-end CPU time isn't the end-all be-all of optimization. You should always start with your data access layer and the efficiency of the scripts you write. -Sara P.S. - I do disagree with Rasmus' statement about none of us looking at fitting a JIT into PHP. ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HHVM and PHP
On 11/26/2012 09:03 PM, Sara Golemon wrote: P.S. - I do disagree with Rasmus' statement about none of us looking at fitting a JIT into PHP. ;) I think you misread my reply. I specifically said that a JIT is a possibility, just not the HH approach. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HHVM and PHP
On Mon, Nov 26, 2012 at 9:09 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 11/26/2012 09:03 PM, Sara Golemon wrote: P.S. - I do disagree with Rasmus' statement about none of us looking at fitting a JIT into PHP. ;) I think you misread my reply. I specifically said that a JIT is a possibility, just not the HH approach. No no, I caught that. I was just being pedantic in that I *am* looking at fitting a few JIT approaches into PHP (via extensions), including one based on HipHop's approach. :p But if we're still being pedantic, then I should admit to not working too hard on that front. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
