Hi all!
I’ve registered on the wiki with username trowski and would like to request
write access so I can create an RFC for the PR at
https://github.com/php/php-src/pull/1284
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
-interface
Should I just submit that as a separate pull on GitHub and we can discuss it?
Aaron Piotrowski
aa...@icicle.io
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Submitted the pull request: https://github.com/php/php-src/pull/1284
https://github.com/php/php-src/pull/1284
I’m not 100% sure on using the name Error, but Java uses a similar name scheme,
so it isn’t without precedent and it keeps the names shorter.
I also have a branch that prevents user
as trying to write `new
Closure()`) that I could merge if it is decided that the behavior is desired.
Aaron Piotrowski
(Sorry for originally sending this to you directly Sebastian, I’m new to the
list and thought I could just hit reply.)
On May 17, 2015, at 12:07 AM, Sebastian Bergmann sebast
)
⊢ TypeError (replaces TypeException)
∟ ParseError (replaces ParseException)
I’d like to complete a vote before too many alpha releases are made.
I’ll be happy to resolve the merge conflicts in the PR if the vote passes.
Regards,
Aaron Piotrowski
--
PHP Internals
implementing
Throwable.
2) If (1) is accepted, also change EngineException to Error, TypeException to
TypeError, and ParseException
with ParseError, with TypeError and ParseError extending Error.
Regards,
Aaron Piotrowski
, more intuitive names that clarify the separation rather
than
obfuscating it. Throwable and Error make stacked catch blocks cleaner with more
obvious behavior. Voting no means keeping BaseException, EngineException, etc.
that do not extend Exception, but are named as though they do.
Regards,
Aaron
of the second exception branch. It has
precedent
in other languages and is less likely to cause confusion. Most user code that
would
collide with the name is likely very outdated, but still could easily be
updated in
only a few minutes.
Regards,
Aaron Piotrowski
.
There is also a PR open since April 2014 :
https://github.com/php/php-src/pull/659
Actually this has already been fixed for PHP 7, see this commit:
https://github.com/php/php-src/commit/07ecfc7ba9dabc4dfb2a068744b76540308b
Thanks,
Aaron Piotrowski
--
PHP Internals - PHP Runtime
::()
This behavior is inconsistent!
Thanks
Marc
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Thanks,
Aaron Piotrowski
On Jun 10, 2015, at 12:29 PM, Christoph Becker cmbecke...@gmx.de wrote:
Aaron Piotrowski wrote:
Voting is now open on the Throwable Interface RFC:
https://wiki.php.net/rfc/throwable-interface
When will the voting end? It seems to be best to clearly state that in
the RFC also
On Jun 10, 2015, at 10:13 AM, Levi Morrison le...@php.net wrote:
On Wed, Jun 10, 2015 at 9:05 AM, Aaron Piotrowski aa...@icicle.io wrote:
Hello,
Voting is now open on the Throwable Interface RFC:
https://wiki.php.net/rfc/throwable-interface
Not even 24 hours ago you asked
On Jun 15, 2015, at 6:56 AM, Anatol Belski anatol@belski.net wrote:
Hi Dmitry,
-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: Monday, June 15, 2015 10:53 AM
To: Aaron Piotrowski
Cc: Anatol Belski; PHP Internals
Subject: Re: [PHP-DEV] [RFC] Throwable
Hello,
Voting for the Throwable Interface RFC has been changed to remain
open only through today at midnight EST so the patch can be
merged and tested before the next alpha release.
https://wiki.php.net/rfc/throwable-interface
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime
is the time where a) a lot of users will be able to test it
and b) it still can be reverted in the worst case.
What do you think?
Regards
Anatol
I will have some time to resolve the merge conflicts later today, so I will be
happy to take care of that.
Regards,
Aaron
On Jun 10, 2015, at 7:42 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Aaron,
On Thu, Jun 11, 2015 at 2:50 AM, Aaron Piotrowski aa...@icicle.io
mailto:aa...@icicle.io wrote:
On Jun 10, 2015, at 12:29 PM, Christoph Becker cmbecke...@gmx.de
mailto:cmbecke...@gmx.de wrote:
Aaron
Hello,
Resending this notification with the proper subject line.
Voting is now open on the Throwable Interface RFC:
https://wiki.php.net/rfc/throwable-interface
Voting will remain open through June 24th.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
On Jun 15, 2015, at 9:53 AM, Dmitry Stogov dmi...@zend.com wrote:
On Mon, Jun 15, 2015 at 4:55 PM, Aaron Piotrowski aa...@icicle.io
mailto:aa...@icicle.io wrote:
On Jun 15, 2015, at 6:56 AM, Anatol Belski anatol@belski.net
mailto:anatol@belski.net wrote:
Would you like me
fixes in
master.
Kalle, Ferenc, how do you feel about this?
Is changing the voting dates on the RFC to run only through tomorrow
allowed? If so, I can make that change so it can be merged this week.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
, UString::__toString() should cache the
result so multiple casts to the same object are quick.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
a
DivisionByZeroError seems the most appropriate. If a user wants the result of
NaN or Inf it is trivial to write a function for that purpose. Perhaps PHP
could provide such a function.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(__cast() or enabling casting just for UString), as they don't offer any
advantage over writing new UString($string) or UString::fromString($string).
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Anatol,
On Jul 6, 2015, at 8:29 AM, Anatol Belski anatol@belski.net wrote:
Hi Bob,
-Original Message-
From: Bob Weinand [mailto:bobw...@hotmail.com]
Sent: Monday, July 6, 2015 2:59 PM
To: Anatol Belski
Cc: Aaron Piotrowski; internals@lists.php.net
Subject: Re: [PHP-DEV
no functional changes, only more specific types of Errors
are thrown from conditions that were already throwing Error objects.
I was hoping this could be merged before beta 1, though I’m not sure if the
time table is too tight.
Cheers,
Aaron Piotrowski
and could
be discussed in a future RFC.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Request: https://github.com/php/php-src/pull/1284
https://github.com/php/php-src/pull/1284
Aaron Piotrowski
, while now a
few places now use ZSTR_VAL(zend_string) and ZSTR_LEN(zend_string). Which am I
suppose to use? Do you intend to change every occurrence of direct access to
the struct members to use the macros instead?
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing
Quickly applying bug fixes.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(and quite frankly, from zpp calls in all functions, including old functions).
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
error for programmers to not do a strict check using === against false when
calling strpos().
Does anyone have a strong objection to the above proposal? If not, then I think
Sammy should update his PRs to throw an Error so they can be merged before the
next beta release.
Aaron Piotrowski
--
PHP
be satisfied that other internal functions already can behave similarly, and
those looking to fail closed can be satisfied that an exception will be thrown
if securely generating a random value fails.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
On Jul 13, 2015, at 1:56 PM, Dean Eigenmann dean.eigenm...@icloud.com wrote:
I have updated the RFC with a new section showing the updates
Sent from my iPhone
On 13 Jul 2015, at 20:47, Benjamin Eberlei kont...@beberlei.de wrote:
On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann
current behavior of method and property visibility.
Interfaces should only be allowed to have public constants. Protected constants
would infer that the interface knows something about implementation, which
doesn’t make sense for an interface. I think the RFC should be updated to
remove this ambiguity.
I’m not sure if this would require the vote to be restarted, as I doubt anyone
who voted yes would now vote no with this change.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
given the chance to be executed. This behavior is similar to
async/await, instead using a generator as the async function and yield as
await. There are several packages available for Icicle that implement
non-blocking I/O and concurrency (multithreading). There are no extensions
required for Icicle and no black magic – just making good use of the tools
already available.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in Icicle,
blocking control flow at that point until the promise is resolved. Perhaps in
this way existing functions could be modified to support async/await while
maintaining the existing blocking behavior when called without the await
keyword.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Develo
There is no way of knowing if the stream buffer is full before calling
fwrite(), resulting in a warning and 0 being returned. IMO, just 0 should be
returned without issuing a warning.
Aaron Piotrowski
https://trowski.com
@trowski2002
--
PHP Internals - PHP Runtime Development Mailing List
r to
calling these functions. Setting a custom error handler before calling these
functions and removing the error handler afterwards is a clunky solution. Any
proposal to remove the @ operator needs to address how functions issuing
unavoidable warnings will be changed.
Aaron Piotrowski
https://trowski.com
@trowski2002
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/rfc/iterable
<https://wiki.php.net/rfc/iterable>
Thanks!
Aaron Piotrowski
/throw_error_in_extensions
PR: https://github.com/php/php-src/pull/1942
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ists for no obvious reason. A function should not be called if too few
arguments are provided.
While this might be considered a BC break, I can't imagine there's an actual
code out there relying on suppressing the warning just to call a function
without enough arguments. I see no problem putting th
> On Jun 1, 2016, at 3:56 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
>
> On 01/06/2016 19:36, Aaron Piotrowski wrote:
>> While this might be considered a BC break, I can't imagine there's an actual
>> code out there relying on suppressing the warning just to
clarations using other interfaces such as `Iterator`
or `IteratorAggregate`, using `iterable` was about equal in performance. [6]
Overall in my opinion, the performance impact of this RFC is negligible.
Dmitry, could you take a look at the patch and do some of your own performance
checks?
Thanks!
Aaron P
Hello,
Voting on the Iterable RFC has opened and will remain open until 7/2/16 at
11:59 GMT.
https://wiki.php.net/rfc/iterable
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable) to a
vote in about a week, does anyone have any further feedback on this proposal?
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
om/php/php-src/pull/1942
<https://github.com/php/php-src/pull/1942>
Aaron Piotrowski
t;
While this is somewhat off-topic of this particular RFC, since we can already
do general type-aliasing with `use`,
use SomeFoo as Foo;
perhaps similar syntax could be used for type expressions, eliminating the need
for a new keyword.
use callable(int, int): int as IntReducer;
use array |
to modify overall
error handling in each extension. I would rather individual extension
maintainers make decisions on error levels.
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, regardless of nullability. Casting should
not be required to get information from an object, but currently this is the
only way to get the type name from ReflectionType. Most other reflection
classes include a getName() method, this seems to have been an oversight.
Joe and Davey, what are yo
Hi Levi,
> On Jul 9, 2016, at 10:12 AM, Levi Morrison <le...@php.net> wrote:
>
> On Sat, Jul 9, 2016 at 8:16 AM, Aaron Piotrowski <aa...@trowski.com
> <mailto:aa...@trowski.com>> wrote:
>>
>>
>> Additionally, I propose adding a getName() method
ld still like each extension maintainer to take a look at the
changes made to ensure I have not missed cleaning up cases where bail-out
behavior was being relied upon.
Cheers!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
attention to an RFC before voting actually opens. There seems to be a pattern
of issues with RFCs not being discussed until voting has begun. The pre-vote
phase could replace one week of the discussion period, so an RFC would still
only need a minimum of two weeks between announcement and voting.
ay was a reasonable and simple requirement to allow an
instance of stdClass to be iterable. I do not think stdClass was designed for
iteration, but rather is just used this way because of the behavior of foreach.
I'd prefer json_decode() to return an iterable object... maybe an RFC for
another day.
Aaron Piotrowski
ill no longer work, or that it will still work, but stdClass would not
> be instanceof Iterable?
That code will continue to work just as it always has. stdClass will not be
accepted by the iterable type.
Aaron Piotrowski
is has been fixed perhaps it should be avoided in your
use-cases.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t now I'm not seeing a way of
handling nullable types in ReflectionType::__toString() without some sort of BC
break.
Aaron Piotrowski
.
If anyone has objections to these changes, please let me know.
Thanks!
Aaron Piotrowski
[1]
http://git.php.net/?p=php-src.git;a=commitdiff;h=20fdd47921f423728b409fd0ae0106dab9c34573
[2] http://news.php.net/php.internals/94452
[3] https://wiki.php.net/rfc/reflectiontypeimprovements
[4] https
think no matter what is done, nullable types just created
another headache for you. :-(
Aaron Piotrowski
[1] https://github.com/php/php-src/pull/2068#issuecomment-239983716
(Forgot to CC internals again... ugh)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ring a closure.
Below are a couple of real-world single line closures using the proposed syntax:
[1] Loop::defer(|| => ($this->when)($exception, $value));
[2] $this->watcher = Loop::delay($time, || => $this->resolve($value));
IMHO, the reduced boilerplate required makes it eas
is not followed by =>, the parser should be able to discern
that a union type is being used.
Regards, Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Feb 3, 2017, at 9:06 PM, Stephen Reay <php-li...@koalephant.com> wrote:
>
>
>> On 4 Feb 2017, at 07:25, Aaron Piotrowski <aa...@trowski.com> wrote:
>>
>> $callback = |int|float $x| => $x ** 2;
>
> Forget the parser, you're giving my eyes d
nfusing when something like `|| => $x ** 2` may be
more confusing, so point taken. Regardless, I still prefer the visual
difference since the auto-capture behavior is so different from other functions.
Cheers!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hod. The rest of the RFC was not
implemented. This should be completely BC while allowing future types like
unions or callables. See some discussion here:
https://github.com/php/php-src/pull/2068
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Jun 7, 2017, at 6:31 AM, Derick Rethans <der...@php.net> wrote:
>
> I voted no because of the BC break.
>
Changed my vote to no for the same reason. The subtly of the BC would make bugs
potentially difficult to discern. Would happily vote yes again for an RFC
t
What keywords do you like for fibers and why do we need them?
> Why do we need Promise/Awaitable in the core?
> If you have concrete solution (just API), lets discuss it in separate email
> thread.
Niklas and/or I will put something together and start a new thread.
Regards,
Aaron Piotrowski
y ready to shine in environments outside of
per-request SAPIs. Core support for async is one of the few ingredients missing.
Aaron Piotrowski
[1] https://github.com/amphp/green-thread
[2] https://github.com/amphp/byte-stream/tree/ext-fiber
[3] https://github.
ility for function autoloading and further optimizations.
+1
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ibers
to be returned from methods, named functions, etc with less boilerplate.
Thanks to you and Dmitry for working on this!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
o
much is filtered because a banned person is CC'ed on a constructive comment, or
too little is filtered and there's still noise from those replying to the
filtered user. Banning or suspension should not be used lightly, but I think
we've reached a point where it is warranted.
I think a simple P
b233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
>>
>> <https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916>
>>>
>>> No catch block would catch it, because it wouldn't implement Throwable
>> nor extend Exception or Error.
>>>
>>
>> Very elegant solution!
>>
>> PS: Naming things is hard, but `Throwable` could not have been a
>> better choice in retrospect. Ty ;)
Thanks! Every once-in-a-while I manage to name something correctly!
>>
>>> Aaron Piotrowski
>>>
>>
>> Márcio
Aaron Piotrowski
licitly catching the exit.
>
> 3. Introducing a function like catch_exit(function() { ... }). This would
> still allow catching exits (for phpunit + daemon use cases), but the fact
> that this is actually implemented based on an exception would be hidden and
> the only way to catch the exit is through this function.
>
> 4. Don't allow catching exits at all. In this case the exception is just an
> implementation detail.
>
> Nikita
+1 for option 3.
EngineShutdown could be a special exception to the engine, being handled like
an exception internally, but not implement Throwable and therefore not an
exception from user-land's point-of-view.
EngineShutdown could be added to the list of "throwables", but forbid
instigation in user-land.
https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
No catch block would catch it, because it wouldn't implement Throwable nor
extend Exception or Error.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
future, but for
logically grouped classes (such as DOM), extensions, etc.
Attributes are a basic language feature, and therefore should live in the
global namespace the same way as Throwable, Iterator, Countable, etc.
I did not want naming to be a blocker on the attributes RFC, but it certainly
bo
are a complex feature. The RFC contains many examples and links to code
using fibers to help explain and demonstrate what is possible, however I’m
certain many more questions and concerns will arise. Looking forward to
feedback and discussion.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development
fibers offer a distinct advantage to using promise for
async code.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nc` and return an Awaitable. Your example declares
`async_task()` as async, while a similar function using the proposed fiber API
would not need to change the function declaration to use `Fiber::suspend()`.
There's an example in the RFC using `Amp\delay()` that is very similar to your
code sample.
> On Dec 21, 2020, at 4:33 PM, Mike Schinkel wrote:
>
>> On Dec 17, 2020, at 11:30 AM, Aaron Piotrowski wrote:
>>
>> Hello everyone!
>>
>> I would like to introduce an RFC for adding full-stack fibers to PHP:
>> https://wiki.php.net/rfc/fibers
>
't hesitate to ask.
Cheers!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/examples/pipeline or in react-fiber
https://github.com/trowski/react-fiber/tree/master/examples where the Fiber API
is handled by the library rather than “application” code.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
I had issues when trying to implement this in the
extension during shutdown due to stacks being freed. Something I think can be
addressed if adding to core with the help of someone more familiar with how
references to these stacks are kept and what should be modified in the
functions generating backtraces.
i Levi,
Yes, I agree and will look at implementing an observer API.
Cheers,
Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> <https://www.php.net/unsub.php>
Scheduler internally is just another fiber, there’s nothing really
special done to switch to a fiber scheduler. Requiring suspending to a
scheduler rather than an arbitrary fiber prevents users from attempting to
switch to an already running fiber.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
/7155
Nothing has functionally changed about the method, only the name.
Fiber::current() is another possibility, but was not chosen because it may be
conflated with Iterator::current().
Does anyone object to this rename? Shall we have a vote or is that not
necessary?
Cheers,
Aaron Piotrowski
> On May 14, 2021, at 6:09 PM, Paul Crovella wrote:
>
> On Fri, May 14, 2021 at 2:49 PM Aaron Piotrowski wrote:
>>
>> Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as
>> `$partial = foo(?, 42)`.
>>
>> If the partial i
On May 14, 2021, at 7:36 PM, Larry Garfield wrote:
>
> On Fri, May 14, 2021, at 7:20 PM, Aaron Piotrowski wrote:
>>
>>> On May 14, 2021, at 7:00 PM, Larry Garfield wrote:
>>>
>>> Is that actually going to come up? Given that PHP functions (at least
>
e forwarded to `$z` or
should the call error as providing too few arguments? Or perhaps should the
partial declaration should error, as it should have been `foo(?, 42, ?)` or
`foo(?, 42, ...?) so the partial provided all required arguments to foo.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP R
l four
params: `fourParams(1, 2, 3, 4, ?)`.
What would error is `fourParams(1, 3, ?, ?)`, as the second ? is meaningless.
I think you've convinced me that one-for-one matching on ? is burdensome, but
the above is a happy medium perhaps?
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Devel
go when I started compiling PHP
myself and was confused why `php -a` broke. An error message would have saved
me some time. So yes, please, merge it.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ially chose `noreturn` simply because I
was familiar with the name from C and didn't have a strong opinion. However, I
agree that `noreturn` is a poor choice for reuse as a bottom type, so I changed
my vote to `never`.
Cheers,
Aaron Piotrowski
r on from the RFC, does this also deprecate
> random_int()/random_bytes()? Those are (AFAIK) unseeded, so they seem like
> they'd continue to serve their current purpose, but it's not clear from the
> RFC.
>
> Voting no for now, but I would welcome a resubmission with a cleane
d by PHP for fibers, allowing it to drop the
boost dependency.
This leads me to believe my proposal would be mutually beneficial to both your
extension and the wider PHP community that could use fibers outside of your
framework or Swoole.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime De
e PHP users, we
> believe there would be little effect to the community to take this step.
>
> Cheers,
> Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi everyone!
I’m concerned my email
all the tools for fantastic, clear, intuitive user space
async code. This is the one missing piece.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
able to
PHP extensions.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> On Mar 11, 2021, at 10:41 AM, Ben Ramsey wrote:
>
>> On Mar 11, 2021, at 10:29, Aaron Piotrowski wrote:
>>
>> There is not an internal API to create fibers at this time. However, I
>> planned to collaborate with other internals developers to add this API (a
> On Mar 12, 2021, at 4:36 PM, Christoph M. Becker wrote:
>
> On 12.03.2021 at 23:04, Michael Wallner wrote:
>
>> Thank you, and everyone involved, for your effort.
>>
>> On 08/03/2021 20.40, Aaron Piotrowski wrote:
>>> Greetings everyone!
>>
> On Mar 8, 2021, at 1:40 PM, Aaron Piotrowski wrote:
>
> Greetings everyone!
>
> The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers
> <https://wiki.php.net/rfc/fibers>
>
> Voting will run through March 22nd.
>
> Cheers,
> Aaron Pi
do
not condone sending emails to people privately off list asking them to vote in
a particular way.
For clarification to those that may have not received the email in question, I
did not send the email nor did I request that it be sent.
Thanks,
Aaron Piotrowski
--
PHP Internals - PHP Runtime D
ant to be a lightweight implementation to enable user
space green-threads/coroutines. I would love to see more async tools in PHP,
but that will require much more work. This is meant to be a first step toward
that eventual goal, without conflicting with or restricting future additions.
Cheers,
es.
- Being marked experimental: I was hoping this would be a good compromise
between allowing people to experiment with fibers and providing the ability to
make minor BC breaks if the need arose. I realize this is generally not the PHP
way, however this is, IMO, not entirely without precede
> On Mar 19, 2021, at 5:47 PM, Levi Morrison
> wrote:
>
> On Fri, Mar 19, 2021 at 3:54 PM Niklas Keller <mailto:m...@kelunik.com>> wrote:
>>
>> Hey Levi,
>>
>>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski wrote:
>>>&g
echo $result, "\n";
$result = $fiber->resume();
}
echo "Generated ", $i, " numbers before generating zero.\n";
```
This short script works just as expected, cool! :-D
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
1 - 100 of 108 matches
Mail list logo
