Am 29.11.2023 um 08:12 schrieb Derick Rethans:
Not really, as a hash doesn't directly tell me the date/time, and neither would
it help in dev branches / checkouts where the latest changes haven't been
comiited yet.
I do not see how date/time help with seeing what was compiled.
--
PHP
> On 29 Nov 2023, at 09:58, Larry Garfield wrote:
>
> On Tue, Nov 28, 2023, at 7:49 PM, Juliette Reinders Folmer wrote:
>> L.S.,
>>
>> What with all the drives towards cleaner code, how do people feel
>> nowadays about `extract()` and `compact()` still being supported ?
>>
>> Both have
On 29 November 2023 00:48:28 GMT, Matthew Weier O'Phinney
wrote:
>On Tue, Nov 28, 2023, 5:28 PM Derick Rethans wrote:
>
>> On 28 November 2023 17:28:18 GMT, Sebastian Bergmann
>> wrote:
>>
>> >While we could probably replace __DATE__ and __TIME__ with
>> SOURCE_DATE_EPOCH [3] [4], I cannot
Am 28.11.2023 um 19:40 schrieb Ilija Tovilo:
At least for core, enabled-by-default extensions, __DATE__ and
__TIME__ seem to be the only variables. I can get reproducible builds
by setting SOURCE_DATE_EPOCH.
Confirmed: I can get reproducible builds, too, by using CLANG and setting
Am 29.11.2023 um 07:23 schrieb Sebastian Bergmann:
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%cI) should do the trick.
What I meant to write was SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct), of
course. Sorry for the noise.
--
PHP Internals - PHP Runtime Development Mailing List
To
Am 29.11.2023 um 01:54 schrieb Marco Pivetta:
Also, refs have a timestamp :-)
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%cI) should do the trick.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Tue, Nov 28, 2023, at 7:49 PM, Juliette Reinders Folmer wrote:
> L.S.,
>
> What with all the drives towards cleaner code, how do people feel
> nowadays about `extract()` and `compact()` still being supported ?
>
> Both have alternatives. The alternatives may be a little more cumbersome
> to
L.S.,
What with all the drives towards cleaner code, how do people feel
nowadays about `extract()` and `compact()` still being supported ?
Both have alternatives. The alternatives may be a little more cumbersome
to type, but also make the code more descriptive, lessens the risk of
variable
On Wed, 29 Nov 2023 at 01:48, Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:
> On Tue, Nov 28, 2023, 5:28 PM Derick Rethans wrote:
>
> > On 28 November 2023 17:28:18 GMT, Sebastian Bergmann
> > wrote:
> >
> > >While we could probably replace __DATE__ and __TIME__ with
> >
On Tue, Nov 28, 2023, 5:28 PM Derick Rethans wrote:
> On 28 November 2023 17:28:18 GMT, Sebastian Bergmann
> wrote:
>
> >While we could probably replace __DATE__ and __TIME__ with
> SOURCE_DATE_EPOCH [3] [4], I cannot help but wonder whether having the date
> and time when the executable was
> Use zend.script_encoding=sjis and zend_bultibyte=true
>
> ❯ ~/php82/bin/php -d zend.script_encoding=sjis -d zend.multibyte=true
> deprecate_zend_scriptencoding.php
> array(7) {
> ["biao_hex"]=>
> string(6) "e8a1a8"
> ["zend.multibyte"]=>
> string(1) "1"
> ["zend.script_encoding"]=>
>
2023年11月29日(水) 9:04 Hans Henrik Bergan :
>
> Do you have access to a project actually using Shift_JIS? Interesting!
> I thought they were practically unicorns / non-existent running PHP4,
>
> Can you run
> ```
> var_dump(array(
> "biao_hex" => bin2hex("表"),
> "zend.multibyte" =>
actually scratch that, run
```
var_dump(array(
"biao_hex" => bin2hex("表"),
"zend.multibyte" => ini_get("zend.multibyte"),
"zend.script_encoding" => ini_get("zend.script_encoding"),
"zend.detect_unicode" => ini_get("zend.detect_unicode"),
"mbstring.internal_encoding" =>
Do you have access to a project actually using Shift_JIS? Interesting!
I thought they were practically unicorns / non-existent running PHP4,
Can you run
```
var_dump(array(
"biao_hex" => bin2hex("表"),
"zend.multibyte" => ini_get("zend.multibyte"),
"zend.script_encoding" =>
2023年11月29日(水) 8:07 Hans Henrik Bergan :
>
> @youkidearitai right now the code specifically deals with
> - UTF8: removing UTF8 BOM and removing `declare(encoding='UTF-8');
> - UTF16LE/UTF16BE/UTF32LE/UTF32BE: converting to UTF8 removing the BOM
> and removing declare(encoding='...')
> -
On 28 November 2023 17:28:18 GMT, Sebastian Bergmann wrote:
>While we could probably replace __DATE__ and __TIME__ with SOURCE_DATE_EPOCH
>[3] [4], I cannot help but wonder whether having the date and time when the
>executable was built in the executable is actually useful. How attached are we
@youkidearitai right now the code specifically deals with
- UTF8: removing UTF8 BOM and removing `declare(encoding='UTF-8');
- UTF16LE/UTF16BE/UTF32LE/UTF32BE: converting to UTF8 removing the BOM
and removing declare(encoding='...')
- ISO-8859-1: converting to UTF-8 and removing
2023年11月29日(水) 7:41 Hans Henrik Bergan :
>
> btw if we come to some consensus to my php2utf8.php script is actually
> worthwhile to expand on, i can volunteer to add more encodings (SJIS,
> BIG5, anything supported by mbstring),
> but it wouldn't surprise me if a better approach exist and the
On Tue, Nov 28, 2023 at 12:48 PM Hans Henrik Bergan
wrote:
> >If the solution is as easy as just converting the encoding of the
> source file, then why did we even need to have this setting at all?
> Why did PHP parser support encodings that demanded the introduction of
>
> I've read your
btw if we come to some consensus to my php2utf8.php script is actually
worthwhile to expand on, i can volunteer to add more encodings (SJIS,
BIG5, anything supported by mbstring),
but it wouldn't surprise me if a better approach exist and the script
should be rewritten entirely~
>add that what's
> What is the migration path for legacy code that use those directives?
The migration path is to convert the legacy-encoding PHP files to UTF-8.
Luckily this can be largely automated, here is my attempt:
https://github.com/divinity76/php2utf8/blob/main/src/php2utf8.php
but that code definitely
> Le 28 nov. 2023 à 20:56, Kamil Tekiela a écrit :
>
>> Convert your PHP source files to UTF-8.
>
> If the solution is as easy as just converting the encoding of the
> source file, then why did we even need to have this setting at all?
> Why did PHP parser support encodings that demanded the
> Convert your PHP source files to UTF-8.
If the solution is as easy as just converting the encoding of the
source file, then why did we even need to have this setting at all?
Why did PHP parser support encodings that demanded the introduction of
this declare?
--
PHP Internals - PHP Runtime
On Nov 28, 2023, at 11:12, Claude Pache wrote:
> Le 28 nov. 2023 à 19:57, Hans Henrik Bergan a écrit :
>> With the dominance of UTF-8 (a fixed-endian encoding), surely no new
>> code should utilize any of declare(encoding='...') / zend.multibyte /
>> zend.script_encoding / zend.detect_unicode.
Hi Hans,
Can you share a little more details about how this works? This is a
pretty niche functionality, so most people probably don't know what it
is, how it works, or why it should no longer be used. Also, as Claude
mentioned, what is the preferred alternative?
Regards,
Kamil
--
PHP
> Le 28 nov. 2023 à 19:57, Hans Henrik Bergan a écrit :
>
> With the dominance of UTF-8 (a fixed-endian encoding), surely no new
> code should utilize any of declare(encoding='...') / zend.multibyte /
> zend.script_encoding / zend.detect_unicode.
> I propose we deprecate all 4.
Hi,
What is
With the dominance of UTF-8 (a fixed-endian encoding), surely no new
code should utilize any of declare(encoding='...') / zend.multibyte /
zend.script_encoding / zend.detect_unicode.
I propose we deprecate all 4.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Tue, 28 Nov 2023 at 19:40, Ilija Tovilo wrote:
> That said, I wouldn't object to removing the date either.
>
Wishful thinking, but perhaps a GIT ref of some sort would be a good
replacement too, if the working copy is clean.
I wouldn't put too much weight on it, but that would certainly
Hi Sebastian
On Tue, Nov 28, 2023 at 6:28 PM Sebastian Bergmann wrote:
>
> I recently watched a video [1] that once again brought the topic of
> reproducible builds [2] to my attention.
> ...
> I have not yet checked whether usage of the __DATE__ and __TIME__ macros
> is the only thing that
I recently watched a video [1] that once again brought the topic of
reproducible builds [2] to my attention.
I believe that reproducible builds are becoming more and more important
and that the build of the PHP interpreter/runtime should become reproducible.
Right now, compiling the same
On 28/11/2023 09:54, Claude Pache wrote:
The big problem with the `callable` type, is that it can be check only at
runtime. For instance:
```php
function foo(callable $x) { }
foo('strlen'); // ok
foo('i_dont_exist'); // throws a TypeError
```
To expand on this example, and address the
> Le 28 nov. 2023 à 00:59, Sergii Shymko a écrit :
>
> Hi,
>
> Wanted to bring up an inconsistent behavior of callable arguments compared to
> arguments of other types.
> Callable argument cannot have a default value (tested string or array types -
> both are not permitted).
> The same
On Tue, Nov 28, 2023 at 12:59 AM Sergii Shymko wrote:
>
> Hi,
>
> Wanted to bring up an inconsistent behavior of callable arguments compared to
> arguments of other types.
> Callable argument cannot have a default value (tested string or array types -
> both are not permitted).
> The same exact
33 matches
Mail list logo
