Question to someone who's familiar with how arrays are implemented in PHP.
I've tried asking this on stackoverflow.com, but it looks like I need
to ask this one
to people familiar with PHP source.
PHP manual says that one should only use strings or integers as array keys.
Also I know that PHP does
there something new in this case? i can confirm this behavior with php
5.2.8
open_basedir and paths are correct, same config works in php 5.2.6
bug or expected?
Thanks,
Andre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.
== Introduction ==
This RFC tries to approach the
http://bugs.php.net/bug.php?id=48880 is reason enough to want a
release soon - PHP 5.3 died a very fast death in production here.
for me too. this bug makes 5.3.0 unusable for me. svn is not an option for
production environment.
Thanks,
Andre
--
PHP Internals - PHP Runtime Development
ideas?
Thanks,
Andre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. which is modifying main-html
in 5.2.10 complete page is outputed twice, returning to 5.2.9 page is ok
Also, you can ask your CMS's authors if they know about this problem
i think problem is unknown but will ask there.
maybe we succeed to isolate problem.
Thanks,
Andre
--
PHP Internal
amp; ~E_NOTICE & ~E_DEPRECATED
timezone is also set which was in relation to duplicate reports:
date.timezone = "Europe/Berlin"
how to solve this if it is really not a bug?
Thanks,
Andre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
I'm not 100% sure, but I believe this is related:
http://bugs.php.net/bug.php?id=50251
ohh yes, did not found this report by previously searches :/
Thanks, could use this patch...
Andre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
Am 05.09.2010 um 15:06 schrieb Johannes Schlüter:
> preg_match('/PHP (.*) swesome/', 'PHP is awesome', $matches);
>
preg_match should be slower?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I was thinking about passing an array at first. But because of bloated handling
of correct type of each argument in the array I use an object for passing
additional "setting" variables.
Von meinem iPhone gesendet
Am 15.10.2010 um 19:28 schrieb "Michael Shadle" :
> On Fri, Oct 15, 2010 at 10:26
Maintaining the documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
What are your thoughts about syntax such as the following, similar to the
syntax for Java (only for use of functions/constants from the root scope)
https://marc.info/?l=php-internals&m=151788196501507&w=2 . (I couldn't find any
other mentions after a quick search)
Benefits of "use function *"
I implemented a PR for this if you wanted to know how this will work and how
edge cases will be handled.
https://github.com/php/php-src/pull/4951
> I was assuming that the ultimate goal was to remove (after deprecation) the
> fallback to global namespace.
> In that regard, the `use function *`
My previous message can be seen at https://news-web.php.net/php.internals/107887
(marc.info seems to show it as base 64 encoded text.)
It links to a PR https://github.com/php/php-src/pull/4951 implementing this
>A more cosmetic consideration is that the more generic the syntax looks,
>the more
Hi internals,
This RFC proposes to support an opt-in "use global functions/consts;" statement
to disable PHP's check for the function/const in the current namespace before
falling back to the global namespace.
https://wiki.php.net/rfc/use_global_elements
Earlier discussion can be found in the
> Do you have plans to use the https://github.com/php/php-rfcs to promote the
> discussion as well, the same way
we did https://github.com/php/php-rfcs/pull/1 for the Typed Properties RFC?
No, I have no plans to switch to GitHub. At the time of writing,
https://github.com/php/php-rfcs/blob/maste
> It's an interesting idea, but at this time I think it's the wrong
> approach to what is in the best long-term interests of the language by
> introducing an additional point of inconsistency.
>
> Classes search the current namespace, but functions / const would search
> namespace first, unless
> We might eventually benefit from versioned "libraries" of functions that can
>be imported in one command
> which would solve many-a-future-problem by itself.
I'd be in favor of a module system, I just can't think of a good way to migrate
to that with existing limitations.
I'd imagine there wou
> The problem with using constants is that the value is still hardcoded
> and if we later want to change to pulling the data from a config file
> we have to change all the code that uses those constants.
It's possible to work around this by using a unique constant name
and define('unique_name',
After a quick search, it turns out I've mostly reinvented
https://wiki.php.net/rfc/autofunc which I hadn't remembered.
The `spl_autoload_*()` changes it mentions is what I had in mind
There's been changes to php since then, it's been 7 years,
and this adds thoughts on some implementation details.
> Could you expand on what you mean by "ambiguous" / "unambiguous" here?
I started the thread "Autoloading functions/consts without a performance impact"
for any other discussion on autoloading. It clarifies what "ambiguous" means.
In my earlier comments, I didn't realize https://wiki.php.net/rfc/
> If we cache the resolution to global function at line 2, removing that line
> changes the rest of the program. If we don't cache it there, then what
> happens if we run this code in a loop?
It (and my proposed autoloader change)
changes it for that call (at that opcode, i.e. for the call at that
> Now the behaviour of my program can completely change depending on which of
> those functions I call first, which might even depend on user input.
> Regardless of exactly how the cache works, that kind of unpredictability is
> a recipe for disaster.
It already does completely change depending on
> If the call to foo() is simply treated equivalently to a call to A::foo(),
> then this may have some quite surprising behavior:
>
> If A::foo() is an instance method, then this call to foo() will inherit
> $this,
> which is something that normally does not happen with free-standing function
>
> Yes, I'm saying that the autoloader should be called for each lookup, so
> autoloading of Foo\strlen should come between checking if Foo\strlen is
> defined, and checking if \strlen is defined.
That would be the intuitive approach for a language,
but as mentioned earlier,
it would significantly
I have a work in progress wrapper for allowing const-like syntax for global
constants `static const X = $dynamicExpression;`.
This can be seen in https://github.com/TysonAndre/php-src/pull/10
This is basically a wrapper around if (!defined(...)) { define(...); }
If anyone's planning to implement c
> const DEBUG_MODE = false;
>
> function foo() {
> if (DEBUG_MODE) {
>// Do stuff.
> }
> }
>
> PHP will currently (AIUI) inline the DEBUG_MODE value at compile time,
> notice that the code path is unreachable, and omit it from the compiled
> opcodes entirely.
> (I'm pretty sure it does th
> This RFC proposes to support an opt-in "use global functions/consts;"
> statement
> to disable PHP's check for the function/const in the current namespace before
> falling back to the global namespace.
>
> https://wiki.php.net/rfc/use_global_elements
>
>
> Earlier discussion can be found in
I'll be postponing the vote to update the RFC and proof of concept/tests
associated with it to use declare()
Also, "declare(lookup_functions_in_current_namespace = false,
lookup_consts_in_global_namespace = false)" in the file's declare() blocks was
my first idea.
Any ideas - declare(disable_am
> Wow. From a participation standpoint that seems pretty pathetic. If 30 is the
> average that means most people never vote.
>
> I would have assumed that having a vote would mean that people would be
> expected to vote periodically or if not then loose the privilege.
How many of the 1900 are
> I'm unsure of exactly how this might work so defer to an Internals export,
> but having previously read @Nikita Popov 's great
> post on PHP's arrays, I did wonder if by knowing the data type within an
> array and that it'd conform to a strict structure, could the array itself
> be stored in an a
> I have a PR that reduces the [minimum capacity of a packed array from 8] to
> 2, noticeably decreasing memory -
> the largest blockers were getting a realistic idea of whether commonly used
> applications
> would see a decrease or increase in runtime, and needing code review.
Sorry, I forgot
Hi internals,
After feedback, the RFC syntax has been changed from `use global functions` to
`declare(disable_ambiguous_element_lookup=1)`. In addition,
- The two settings have been combined into a single option,
which is now declare(disable_ambiguous_element_lookup=1) at the top of a file.
> I'd much rather have something like:
>
> declare(ambiguous_element_lookup=0)
>
> declare(ambiguous_element_lookup=off)
Aside: declare(unambiguous_element_lookup=1) is probably a better choice than
my first choice of (disable_ambiguous_element_lookup=1), but probably not the
best choice.
> I
> > One option that I haven't seem much discussion on is the opposite: Always
> only look in the global namespace. Any unimported unqualified usages will
> > be treated as fully qualified names. This would match the proposed
> > semantics for functions/consts and change the resolution rules for cla
> I like the idea of using a meaningful value here, but think that this
> should be using a string, i.e. declare(function_and_const_lookup='global')
> rather than declare(function_and_const_lookup=global).
Also, I could make that a voting option, and it could be changed before 8.0
alphas if new
I've also put together a *different* proof of concept adding support for named
calls of global functions
(and only that, no other new allowed types of expressions) from within the
expressions of constants.
(i.e. global constants, class constants, and parameter defaults).
I was considering puttin
Hi internals,
https://wiki.php.net/rfc/use_global_elements and the implementation has been
updated again - the syntax is now declare(function_and_const_lookup='global')
with a literal string instead of a keyword.
The voting option for whether it was a string or a keyword was removed.
I plan to m
> and that you have to explicitly say that you use the current namespace for
> that name:
>
> declare(function_and_const_lookup='global');
> namespace MyNS;
> use function MyNS\foo;
> // or, equivalently: use function namespace\foo:
>
> function foo() { }
>
> foo(); // <-- this is the function d
> This would be a compile error right now though, because we don't allow "use"d
> symbols and declarations to clash.
As I surprisingly discovered when implementing the RFC, they don't clash.
The PHP interpreter has a special case where it doesn't warn or throw about the
name being in use
if the
> can we please discuss this alternative? In another reply, you link to
> https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead
>
> But this new proposal derived from Nikita's idea is different as it doesn't
> need to deprecate anything.
I've added
h
> 1. Is it a typo that the first code example in the proposal has a
> namespace declaration before the `declare` statement? Currently it is
> a fatal error if a `strict_types` declaration isn't the first
> statement in a file. Are you intending to change this restriction,
> or have it not apply to
> Imagine this scenario:
>
> * PHP 8 introduces the declare with only 'global' and 'default' options
> allowed, as proposed.
> * PHP 9 makes 'default' a synonym for 'global', because it's now the
> default, and adds a new 'fallback' option
> * I have an application that uses the fallback mode
> I c
https://wiki.php.net/rfc/use_global_elements#implementation_details has been
updated after the latest feedback.
The implementation was also updated.
The opt-in `declare(function_and_const_lookup='global')` directive
now only allows declaring a function or constant in a file if the same name has
> Thanks. It's a bit strange to read the objections to the proposal in the RFC.
> That makes it feel like "we" agreed on them - while it's "only" the author's
> opinion. From this part in the RFC:
It's included because https://wiki.php.net/rfc/howto mentions the following:
"Listen to the feedbac
ant a change to the default mode in the engine
> to cause my code to be interpreted in a different way, so a 'default'
> option makes no sense to me.
I have a better understanding of why you're asking for this now,
but still prefer 'default' and 'global' for the reasons
> I'm encountering a SIGSEGV in PHP-FPM on PHP 7.4.2 in a Symfony app. The
> bug seems to happen during the rendering of a Twig template; this makes it
> hard for me to pinpoint the code that triggers the segfault.
>
> Could you please tell me what the procedure to collect information is, so
> tha
> What do you mean by "weaker"?
Any difference that might be expected by a user when for what differs
between leaving out the setting and setting it to 'fallback'/'default'.
E.g. in my example for `count`, a developer might expect `MyNs\count()`
to continue working as `MyNs\count()` when they se
> > That's more of an objection to 'global' than an argument about 'fallback'
> > or 'default'.
> > It isn't suggesting a name to use instead of 'global'.
> >
>
>
> No, it's saying that whatever name you use, the guarantees of behaviour are
> only as strong or weak as decisions we make in the futur
Hi internals,
I've opened the vote on https://wiki.php.net/rfc/use_global_elements
after weighing the pros and cons of discussed alternative approaches.
Yesterday, I've finished the last set of updates I announced I would do based
on RFC feedback.
(that update was to require the statement 'use f
> Thank you for working to address the issue of ambiguous function references.
> However, I really don't think this is the right approach.
>
> The RFC mentions two problems it hopes to solve: a minor performance
> decrease, and developers having to deal with ambiguity.
> However, a third problem
>> I'm encountering a SIGSEGV in PHP-FPM on PHP 7.4.2 in a Symfony app. The
>> bug seems to happen during the rendering of a Twig template; this makes it
>> hard for me to pinpoint the code that triggers the segfault.
>
> I'm not sure if I could gather helpful enough info about the issue, but
> any
Sorry, I didn't notice that https://bugs.php.net/bug.php?id=79194 was already
closed with a similar answer.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Sorry, I didn't notice that https://bugs.php.net/bug.php?id=79194 was already
> [solved and] closed with a similar answer.
In addition to phpspy, a tool I forgot to mention was Phan.
(https://github.com/phan/phan)
`phan --redundant-condition-detection` will enable many of Phan's checks,
incl
> Agreed. I want to force explicit qualifications, and raise error on
> unqualified names:
>
> declare(strict_qualify=1);
>
> namespace foo;
>
> use function \{array_diff, var_dump};
> use const \bar\{a, b};
>
> $x = array_diff(a, b);
> if (count($x)) { // throw an \Error of some kind, as count i
Hi internals,
I have a working implementation for calling global functions in constant
expressions at https://github.com/php/php-src/pull/5139
(see PR description for more details, see tests for how edge cases get resolved)
If there was interest, and no implementation or process blockers I wa
> What happens if a function like strlen() is applied to a non-string
> argument? Conversion to string is certainly runtime-dependent even for
> primitive types like floats.
Good point. I thought that string casts were already allowed, but was mistaken.
It's possible to cast to string through conc
> As you've already realized, the main problem here is the behavior for
> functions that have side-effects or state. Currently we mostly get away
> with the illusion that it doesn't matter when exactly constexpr
> initializers are evaluated. Apart from the error location and (admittedly
> quite a f
Hi internals,
> I have a working implementation for calling global functions in constant
> expressions
> at https://github.com/php/php-src/pull/5139
> (see PR description for more details, see tests for how edge cases get
> resolved)
I've written up an early draft of this based on
https://wi
Hi internals,
https://wiki.php.net/rfc/calls_in_constant_expressions has been updated and
moved to
"Under Discussion".
This proposes allowing function calls in constant declarations, static property
defaults,
static variables, and parameter defaults.
It includes a secondary voting option to all
> 1. Why again are MyClass::methodName() not considered for the non-whitelist
> vote?
>
> Seems to me a developer would be more inclined to implement the expressions
> that define the class constant's value in a method of the class than in an
> external function.
My reasons for doing this wer
Hi internals,
https://wiki.php.net/rfc/calls_in_constant_expressions has hit some roadblocks
in the implementation shortly after the last email.
I've been blocked on how to resolve them in the implementation in a way I'm
certain would work.
I had assumed the calling scope wouldn't have the below
> - Solving the above two issues while continuing to throw for func_get_args(),
> get_defined_vars(), etc.
> get_defined_vars() would throw for dynamic calls
Then again, it's already possible to get function parameters through
debug_backtrace(), so implicitly creating a closure and call with 0
My opinion is that it'd be more consistent for `--` to work like `-= 1` (e.g.
become `-1`).
It might break some code, but that code was probably incorrect.
Out of scope of the proposed RFC, but this reminds me of a similar issue:
Currently, the `++` and `--` operators do nothing to arrays or obje
Hi internals,
I've created a straw poll at
https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure
interest in allowing calls in different types of constant expressions.
If there aren't any problems with the poll structure or rules preventing
creating a poll, I was going to add
I'd definitely agree on returning `int` instead of `integer`.
PHP allows both `class integer` and `class resource`, so `int` (plus
documenting exact return values for examples, as Nikita mentioned) would be
useful to prevent ambiguity.
Also, it'd be nice to have `null` return the lowercase stri
> > I've created a straw poll at
> > https://wiki.php.net/rfc/calls_in_constant_expressions_poll ,
> > to measure interest in allowing calls in different types of constant
> > expressions.
>
> I've yet to make my mind up for most circumstances, although I'm leaning
towards a general "No".
>
> Wh
Hi internals,
> I've created a straw poll at
> https://wiki.php.net/rfc/calls_in_constant_expressions_poll , to measure
> interest in allowing calls in different types of constant expressions.
> If there aren't any problems with the poll structure or rules preventing
> creating a poll, I was go
> The original motivation was, IIRC, to initialize class constants with an
> expression.
> Following KISS, I feel we should constrain our efforts to that scope, and
> that's how I voted:
> "Yes" on class constants and static members, "No" on everything else.
I'd also personally found the `static
> I feel like the results of this poll aren't going to be particularly
> meaningful, because it gets too caught up in the details and loses track of
> the big picture.
I'd definitely agree. If I was writing the RFC for calls in constant
expressions again,
I'd focus more on adding concrete example
> What do people think about this? Is there interest in making sorting
> stable? Is it okay to break code using illegal comparison callbacks?
I'd be interested in having a stable sort.
When migrating from php 5.6 to 7 a long time ago,
the fact that sorting was no longer stable was an inconvenience
Hi internals,
One idea I had that was related to this (but not in the scope of this RFC)
would be adding a way to force the interpreter to treat an argument (variable,
array field, property access, etc) as being passed by value,
and refuse to modify it by reference (e.g. emit a notice and create
Hi internals,
In PHP, variables are currently scoped to the function scope, and can't be
scoped to a block scope. This makes it difficult to reason about how a variable
will actually be used at a glance, especially in long functions, or top-level
statement lists of a file.
(or how the variable
> What you are suggesting is that a let statement would switch PHP to an
>altogether different mode where function-scoped and explicit global variables
>were suddenly disallowed and an error within that function (or only after the
>let?).
No, the variables with the *same name* as the variables
> Intuitively, I would expect this:
>
> {
> let $x = new Foo;
> $x->bar();
> }
> somethingElse();
>
> to be equivalent to this:
>
> let $x = new Foo;
> $x->bar();
> unset($x);
> somethingElse();
If this feature freed variables when going out of scope,
it would be compiled more like the f
Hi Mike,
> What I would rather see are new features in PHP that encourage developer
> to break functionality into shorter and simpler functions and methods, and to
> minimize nesting.
I would also like to see shorter functions in general, but:
- Other developers may prefer long functions/script
Hi Rowan,
> Do you know how the equivalent code works with function-scoped variables?
> As far as I can see, returning from a function will successfully call multiple
> destructors even if one of them throws an exception. Could exiting block
> scope use that same algorithm?
PHP literally frees al
Hi Mike,
> What I am about to say is ironic since I too often feel people are trying to
> enforce their view of coding on the world,
> but I do not think we want to give people tools to make it easier to work
> with long functions/scripts.
Blocked-scoped variables is a tool which can make short
> I've searched the archive, but I haven't found anything about this issue.
> I notice there exists an RFC for autoloading of functions, or more to the
> point, a unified autoloading system for classes, functions, constants and
> streams:
Hi Terje,
I'd brought this up 2 months ago in https://e
Hi Craig,
https://github.com/laruence/taint#taint notes that
"Please note that do not enable this extension in product(ion) env, since it
will slowdown your app."
- That repo already provides is_tainted() http://docs.php.net/is_tainted
A fork of that repo would theoretically allow implementi
Hi internals,
I'd just like to add that
https://wiki.php.net/rfc/trailing_comma_in_parameter_list seems useful,
especially now that PSR-12 is approved and
https://www.php-fig.org/psr/psr-12/#45-method-and-function-arguments recommends
that
"When the argument list is split across multiple lines,
> Ah, so that's what this is about! In that case, I'd be happy to simply
> always enforce that __construct() cannot return a value, in the same way we
> do for ": void" functions. (If we have backwards compatibility concerns, we
> can add this as a warning instead of hard error.)
I'd approve of th
Miscellaneous thoughts on this:
- Working to have a vote on https://github.com/php/php-src/pull/4886 might be a
good first step, and something I was personally interested in seeing in 8.0-dev.
However, in the event you can't rule out that is_array($listParam) might not
return true in the final
Hi internals,
Currently, it's possible to disable the json extension with `./configure
--disable-json`.
However, JSON is widely used in many use cases - web sites, logging output, and
as a data format that can be used in CLI programs
to share data with many applications and programming languages
Hi Andrea,
> Since it's pretty simple, I decided to write a proof-of-concept
> implementation of such a check. For simplicity's sake I haven't
> implemented a type declaration right now, just an is_list() function,
> but it could easily be extended to one. The implementation can be found
> at http
Hi Ilija,
> This is because we don't generate a jumptable when there are less than
> 5 integer conditions. Because of this inconsistency I'm not sure if we
> should just remove the warning. As you mentioned, it could be
> intentional in some cases. Tyson also mentioned that some constants
> are pl
Hi Ilija,
1. I was confused by the vote announcement email about what "block statements"
meant - https://github.com/php/php-src/pull/5371#discussion_r415079802
> Thus I have decided to move block expressions to a separate RFC.
This is clarified in https://wiki.php.net/rfc/match_expression#bloc
Hi internals,
I was wondering if the maintainers of the Opcache Jit would be open to work on
optimizing functions such as intdiv(), fdiv(), and spl_object_id() in the JIT
to assembly code when it was safe to do so.
These functions have simple C implementations, so the performance overhead of
ca
Hi Nikita,
> Our general approach to this is to first add a VM opcode for the operation,
> which will also provide a benefit if the JIT is not used.
> There's already plenty of those, see ZEND_STRLEN for example.
> Adding JIT support for the opcode would then be the natural second step.
I've seen
Hi internals,
I've created https://wiki.php.net/rfc/always_enable_json with an implementation
at https://github.com/php/php-src/pull/5495
The proposal is to make it impossible to disable the JSON extension through
configuration or build options,
and require that JSON be built statically instead
Hi internals,
Currently, it isn't possible to enable optimizations without enabling caching.
They should be orthogonal features - it's already possible to cache without
optimization passes (`opcache.optimization_level=0`)
I have a prototype implementing this at
https://github.com/php/php-src/pul
Hi Benjamin,
> > I think it would be best to split up opcache.jit into five separate
> > configuration directives and propose the following names:
> >
> > * opcache.jit for (de)activating JIT
> > * opcache.jit_optimization_level for setting the optimization level
> > * opcache.jit_trigger for conf
Hi CHU Zhaowei,
By alias, I meant "an **alternative** name or label that refers to an item, and
can be used to locate or access it."
(add a way to set the option without removing existing ways)
(Users would have the choice of using both the magic numbers or the strings to
refer to the same sett
Hi internals,
I plan to start the vote for https://wiki.php.net/rfc/always_enable_json on May
13th
> I've created https://wiki.php.net/rfc/always_enable_json with an
>implementation at https://github.com/php/php-src/pull/5495
>
> The proposal is to make it impossible to disable the JSON extensi
Hi Levi,
> Have we reached out to package maintainers for OS distributions that are not
> bundling json today to make sure all their concerns are resolved?
I CCed them on the GitHub PR just now.
https://github.com/php/php-src/pull/5495#issuecomment-623163698
Hopefully, this is due to packaging
Hi internals,
One update before I start the vote for
https://wiki.php.net/rfc/always_enable_json tomorrow (May 13th).
- After feedback from extension authors and php contributors, the C define
`HAVE_JSON` will not be removed as part of this RFC.
I'll leave it to others to decide which php ver
Hi internals,
I have opened the voting for https://wiki.php.net/rfc/always_enable_json
The proposal is to make it impossible to disable the JSON extension through
configuration or build options, and require that JSON be built statically
instead of as a shared library.
The voting period ends on
Hi internals,
I've created the RFC https://wiki.php.net/rfc/opcache.no_cache to make the
opcode optimizer and JIT available without opcode caching, through a new
setting `opcache.no_cache=1`.
So far, the feedback I've gotten is that having the ability to optimize without
caching would be usefu
> In my opinion, configuration names should never be "in the negative".
> Instead of defaulting to opcache.no_cache=0, default to opcache.cache=1.
I see your point - there are only a few negative ini names I see in phpinfo()
(disable_functions, disable_cache), and those are for lists of strings
Hi David,
> You can probably implement this already with PHP's tick functionality
(https://www.php.net/manual/en/function.register-tick-function.php), as
> long as the code in the anonymous function does PHP statements/function
> calls.
>
> If your problem is waiting for an external resource to
1 - 100 of 366 matches
Mail list logo
