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 Interna
> 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 alter
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 help
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
SOURCE_DATE_
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 unsubscribe,
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 ty
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 n
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
> > SOURCE_DATE
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 bui
> 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" => ini_get("ze
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" => ini_get("
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" => ini_get("zen
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='...')
> - ISO-8859-1:
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
declare(encoding='I
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 scrip
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 question
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 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 nee
> 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 Deve
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 Internals
> 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 t
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: https
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 help
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 makes
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 vers
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 origi
> 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 exact
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
