nction get(type $type);
}
I’d appreciate your feedback on this idea before proceeding with an RFC or
draft PR. Please let me know your thoughts!
Best Regards,
Adam Kecskes
nsion was a part of
every PHP build, I'd be advocating to list it as a requirement.
[1] https://github.com/WordPress/blueprints-library/blob/trunk/src/WordPres=
s/AsyncHttp/Client.php
- Adam
ling data between
> PHP and Wasm adds complexity, especially when different programming languages
> are involved.
>
While these are definitely challenges, aren't they largely the same
for most languages intending to support WebAssembly?
– Adam
On Tue, Sep 17, 2024 at 9:17 PM Mike Schinkel wrote:
>
> On Sep 17, 2024, at 8:57 AM, Adam Zielinski
> wrote:
>
> > To summarize, I think PHP would benefit from:
> >
> > 1. Adding WASM for simple low-level extensibility that could run on
> > shared hosts for
Constantly improving PHP the language, which is what you are solely
> advocating for over extensibility,
Hi Mike,
I’m Adam, I'm building WordPress Playground [1] – it's WordPress running in
the browser via a WebAssembly PHP build [2]. I'm excited to see this
discussion and wante
Hi Alexander,
Pls see below my answers.
Best Regards,
Adam.
Adam Hamšík
Co-founder & CEO
Mobile: +421-904-937-495
www.lablabs.io
On 23 Jan 2022, 09:09 +0100, Alexandru Pătrănescu , wrote:
>
> On Sat, Jan 22, 2022 at 10:00 PM Adam Hamsik wrote:
> > Hello,
> >
w we can achieve similar results ?
[1]
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-liveness-probe
[2] https://kubernetes.io/docs/reference/using-api/health-checks/
Best Regards,
Adam.
Adam Hamšík
Co-founder & CEO
Mobile: +421
From: Nikita Popov
Sent: 18 January 2021 10:32
To: Adam Cable
Cc: PHP internals
Subject: Re: [PHP-DEV] Addition of substring and subistring functions.
On Wed, Jan 13, 2021 at 11:51 AM Adam Cable <mailto:a...@adsar.co.uk> wrote:
Hi internals.
I've been coding in PHP for 15 yea
tation can be made a lot better, but it seems to work
OK at present.
This is my first e-mail to internals, so please excuse my naivety with
things, but hope this is useful.
Thanks,
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
the side of caution, and not adopt the change.
>
My take would be that "rules are rules." The RFC was defined as 50%+1.
Thanks,
Adam
better
pattern for driver-specific APIs, but I'm comfortable lumping those goals
under "future scope." Getting parity with ext/sqlite3 will make pdo_sqlite
more usable, which will help grow its community, and the number of people
who are able to contribute to these bigger projects. Deprecating the
current set of driver-specific APIs in the future, if we have functional
equivalents, isn't an impossible project.
Thanks,
Adam
>
> following my patch and discussions on this list, here is the RFC requested
> by some people here to implement "openBlob" in the pdo_sqlite driver, to
> match the "openBlob" method from the SQLite3 extension.
Thanks for taking the time to do the writeup. No objections from me.
Adam
out the right
way to support extension-specific methods would have to figure out how to
deprecate the existing methods. Adding one wouldn't really change the scope
of this problem, which isn't intractable in the greater scheme of things.
Thanks,
Adam
---
[1] https://github.com/php/php-src/blob/master/CONTRIBUTING.md
On Mon, Aug 21, 2017 at 5:54 PM, BohwaZ/PHP wrote:
> Le 22/08/2017 07:55, Adam Baratz a écrit :
>
>> A new method is an API change to me, so an RFC would be warranted. I'm
>> reluctant to add driver-specific methods, since that seems opposed to
>> PDO's
>>
nce that seems opposed to PDO's
driver-agnostic API, but that's not to say we couldn't hash something out.
Thanks,
Adam
On Wed, Jun 21, 2017 at 11:32 AM Christoph M. Becker
wrote:
> On 21.06.2017 at 05:33, Anish Mistry wrote:
>
> > PDO ODBC #42765 uninitialized length bug patch
> > https://bugs.php.net/bug.php?id=42765
> >
> > Any takers? Would we be able to get this patch committed? It's a
> > pretty straight f
_CLASS option referring to that class. There are some
examples in ext/pdo/tests, or you can look at the implementation of
\PDO::prepare() for the nitty gritty.
I think this hook is a good example of the principle I was describing. PDO
may only have a basic set of tools, but it makes it easy to extend
according to your preferences.
Hope this helps,
Adam
. I'm
considering #74592 as a general improvement, separately, in my capacity as
pdo_dblib's maintainer, since it's not practical for everyone to move off
it.
Since your driver uses emulated prepares, I'd expect you having a new
> execution plan regardless. At least for current master, which is the RFC
> target.
I meant if the driver is ever changed to one that uses real prepared
statements.
Thanks,
Adam
ot of agreement in the community, at
least as indicated by discussions on this list.
I agree with Matteo that param hooks might provide a better solution to the
specific problem you're describing.
Thanks,
Adam
d.
In all honesty, I'm ambivalent about this issue. It's certainly not causing
any problems. But if enough people feel it should be removed, I'm happy to
do the work to remove it.
Thanks,
Adam
> > I'm think this problem might've cropped up again. I didn't receive this
> > message:
> > http://news.php.net/php.internals/99052
> >
> > I only heard about it because it was mentioned in a PR thread.
> >
>
> I remember finding this one in the Spam dir (Gmail). It appears that
> DMARC validation
ered:
http://news.php.net/php.internals/99041
At least, some of the responses I was getting made it seem like Matteo and
Marco didn't get all of my posts.
Thanks,
Adam
y use
cases, but the maintainers of the other drivers should decide how they want
to handle floats. I just want to add the hook so the information is there
if anyone wants to use it.
Thanks,
Adam
Hi,
I've heard a few people here mention that this type isn't useful. It looks
like it wouldn't be harmful to remove. The RFC mainly outlines the impact
and proposes a schedule for doing so.
https://wiki.php.net/rfc/deprecate_pdo_null
Please let me know your thoughts.
Thanks,
Adam
to rename the const, from PDO::PARAM_FLT to
PDO::PARAM_FLOAT. Agree that readability is better here. Since there's been
a change, I'll plan on opening the vote tomorrow.
Thanks,
Adam
---
[1] https://github.com/php/php-src/pull/2500
last round respond and say
that these changes won't change their vote, then sure, there's no point in
rerunning this.
Thanks,
Adam
Hi,
I took another pass at this RFC:
> *https://wiki.php.net/rfc/pdo_float_type
> <https://wiki.php.net/rfc/pdo_float_type>*
>
Unless discussion prompts major changes, I'll open this for a vote next
Monday.
Thanks,
Adam
ne who voted "no" previously,
but didn't comment in the thread. There's no need to talk through this RFC
again if everyone in that group wants fixed precision types to be included.
Thanks,
Adam
Hi,
I'm getting a JS error that's preventing this page from loading completely:
https://qa.php.net/pulls/
The error is:
Uncaught TypeError: Cannot read property 'msie' of undefined
(jquery.ba-bbq.min.js:18)
Is anyone able to take a look at this?
Thanks,
Adam
preciate hearing if they had any issues that
weren't covered on the list.
Thanks,
Adam
>
> On 20/04/2017 00:51, Adam Baratz wrote:
> > The reason I went that way was I couldn't find a DB API that
> > differentiates between the two types. They all represent them as a
> > double, so it seemed like a needless distinction to create two PDO
> > types,
do_sqlsrv goes, it's still a "preview." The Linux ODBC driver it
depends on only became supported in January of this year. Eventually, it
could make sense to deprecate pdo_dblib in favor of something supported by
Microsoft, but the timeline for that is unclear.
Thanks,
Adam
pretty rich level of detail in
the RFC.
I'd like to get a better handle on how we should discuss RFCs. We seem to
hit impasses pretty frequently. If you have any specifics on what's helpful
for you, I'm happy to adjust my style.
Thanks,
Adam
Hi,
I'd like to open the vote on this RFC:
*https://wiki.php.net/rfc/pdo_float_type
<https://wiki.php.net/rfc/pdo_float_type>*
Previous discussion:
*https://externals.io/thread/805 <https://externals.io/thread/805>*
Voting will end on the 26th at 0:00 UTC.
Thanks,
Adam
at each of the APIs. My conclusion was that a single
type will be appropriate for floats, doubles, and fixed-precision. I
updated the RFC with details. If it's accepted, it could be worth including
some of this content in the documentation so people better understand the
impact of each PDO param type.
I'll create a separate thread to announce the vote.
Thanks,
Adam
r problems with this or other points to cover.
Otherwise, I'll aim to open voting on Monday.
Thanks,
Adam
to talk through details if you have specific suggestions for
how this type would work in practice.
Thanks,
Adam
tried to be as thorough as possible in understanding the impact on each
supported driver. I'd appreciate any feedback on this concept as well as
its impact on drivers.
Thanks,
Adam
>
> > Wait, when was the vote opened? I didn't receive any notification of that
> > (and therefore didn't vote yet), and we were still telling you in this
> > thread that there are fundamental conceptual issues with the backing
> > reasoning.
>
> Adam an
was accepted. Thanks all for your feedback and
votes.
Adam
etimes you want an array and not a generator. That
language is really sympathetic to generator use, but it never forces you to
use them. The core libraries are structured thoughtfully in that regard.
Thanks,
Adam
others may
need to modify their code to be compatible with this new feature. Within
pdo, a bitmask is applied -- see uses of the PDO_PARAM_TYPE macro. It's
probably worth replicating that in DBAL.
Thanks,
Adam
stions and guide the conversation. There
are some notes here if you haven't done one before:
https://wiki.php.net/rfc/howto
Thanks,
Adam
in?
>
It is true that you get the correct result right now. But this happens
because the DB will automatically cast values that are quoted incorrectly.
This addition would ensures that quoted values don't have an implicit cast
applied, which makes queries more expensive. I can put the links I shared
earlier into the RFC for easier reference.
Thanks,
Adam
Hi,
I'd like to open the vote on this RFC:
https://wiki.php.net/rfc/extended-string-types-for-pdo
Previous discussion:
https://externals.io/thread/715
Voting will end on the 17th at 0:00 UTC.
Thanks,
Adam
I'm exploring how to automate some basic kinds of refactor operations. One
approach I'm considering:
- Generate an AST
- Rearrange it as needed
- Turn it back into userland code
Is this something anyone's explored?
Thanks,
Adam
ortant? Or let me know how I should document things better
in the RFC?
Thanks,
Adam
I updated the RFC based on what I
heard. Hopefully it clarifies some of the ambiguities mentioned and the
motivation for making this change. It's ultimately about helping PDO
articulate part of the SQL spec.
Let me know if you have any new questions/concerns.
Adam
o control delimiters and you might want them to be
driver-specific.
Thanks,
Adam
---
[1]
https://www.postgresql.org/docs/9.2/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING
ontent_CIREYU9
> EA54EOKQ7LAMZKRF6P.html
This functionality seems orthogonal to what I'm describing. It would be
more appropriate to implement this as a driver-specific attribute for
pdo_oci. But since that driver doesn't support emulated prepares, I'm not
sure how much value it would have.
Thanks,
Adam
his as a driver-specific change, but believe
> it's worthwhile to make it generic since it affects multiple drivers:
> https://externals.io/thread/400#email-12542
>
> Please let me know what you think.
>
> Thanks,
> Adam
>
Any thoughts on this one?
ge, but believe
it's worthwhile to make it generic since it affects multiple drivers:
https://externals.io/thread/400#email-12542
Please let me know what you think.
Thanks,
Adam
situation[1]. If at all possible, it'd be better to let an
existing community solve performance issues for you.
The last question should I use call_user_function or write this function
> in C.
>
Call the internal function directly for less overhead.
Hope this helps!
Adam
---
[1] http://regex.info/blog/2006-09-15/247
d on with
https://www.mail-archive.com/internals@lists.php.net/msg88713.html)
My perspective is mainly as someone who works with pdo_dblib. Emulated
prepares make a greater degree of control more desirable in some cases. I
need to think through how such types would impact other drivers, and I've
unfortunately been short on time for the exercise.
Adam
27;s intended to allow toggling. Since this
is a functionality change, I'd suggest supporting it. It'll make it easier
for users to migrate if they have any baked-in assumptions around getting
strings back.
Thanks,
Adam
a look at this one. This is definitely a topic of
interest with the engineers I work with.
Thanks,
Adam
---
[1] https://wiki.php.net/rfc
[2] https://wiki.php.net/rfc/howto
cooled off, so I'd like to open to a vote. Voting will end
> on 16 December 2016 at 0:00 UTC.
>
This RFC was accepted.
Thanks,
Adam
>
> For decimal, double wouldn't be the correct type anyway, as it could
> cause loss of precision.
>
Sure, agree the name is imprecise. "Double" is mainly relevant to zvals.
> Is there a reason PDO::PARAM_DOUBLE doesn't exist?
>
> I don't know if there's am historical reason. I think it should b
PDO::PARAM_DOUBLE doesn't exist?
Thanks,
Adam
to open to a vote. Voting will end
on 16 December 2016 at 0:00 UTC.
Thanks,
Adam
>
> This issue is not difficult to solve in userland, at least well enough for
> debugging in my experience. Here's an older example I wrote up on my blog
> that worked (but I'm told is broken right now): https://daveyshafik.com/
> archives/605-debugging-pdo-prepared-statements.html
>
I want to be
o suggested earlier in this thread: make something more
robust for getting structured data out of statements. To be honest, the v2
RFC does exactly what I need. It'll let me write .phpt tests and do one-off
debugging.
But if your take is that simply that you prefer v1 over v2, the regular
vote should cover that.
Thanks,
Adam
>
> Could you please revert? Albeit minor, it's a new feature and therefore
> it belongs to 7.2.
No problem. Reverted.
>
> I'll incorporate it, and the content of this subthread, in the RFC when I
> get my next free five minutes. :)
>
Done. And because of the scope of the v2 implementation, I changed the
target release to next 7.1.x.
Thanks,
Adam
tatements. Since they're attached to
a pdo_pgsql_stmt value, you'd have to write some driver-specific code to
get them out.
Maybe there's a simple way to do what you're describing, but my instinct is
that it would be better to keep it out-of-scope for this RFC.
Thanks,
Adam
;active_query_stringlen, (int) stmt->active_query_stringlen,
> stmt->active_query_string);
> }
Let me know what you think of this approach. If it sounds fine, I'll update
the RFC.
Thanks,
Adam
Hi,
> Based on my second thoughts on my initial approach, I created an RFC to
> supplant it:
> https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2
>
I'd appreciate any feedback on this RFC, especially from any of the people
who voted against the original[
writing RFCs.
I have some concerns that a very high bar will make it difficult to change
extensions if their users aren't well-represented here.
Thanks,
Adam
Hi,
Based on my second thoughts on my initial approach, I created an RFC to
supplant it:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2
I believe this better addresses the negative feedback from the original
RFC[1] and is a better solution to the problem.
Thanks,
Adam
>
> Once the proposal had been accepted, and merged, it's not really
> legitimate to unilaterally decide that it's a bad implementation and revert
> it yourself.
>
That's fair. I will revert the revert and open a new RFC to supersede the
previous one. Thanks again for your patience.
Adam
marc.info/?l=php-internals&m=147734024403899&w=2
http://marc.info/?l=php-internals&m=147673258418764&w=2
Thanks for your patience as I get acclimated to the world of RFCs.
Adam
Hi,
This RFC reached the 50%+1 vote needed for acceptance:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation
The implementation was added to master (PHP 7.2):
https://github.com/php/php-src/commit/83086d9a72675bad2b2560c6f427d0c1f1d1eba0
Thanks,
Adam
tp://marc.info/?l=php-internals&m=147673258418764&w=2
There were some negatives raised, which I commented on in the RFC.
Voting will end on 14 November 2016 at 0:00 UTC.
Thanks,
Adam
>
> There's value in improving tests for emulated prepares, but as I stated
> somewhere else, I would rather see them deprecated and removed rather
> than encouraged.
>
I left a note about this in the "Future Scope" section[1]. If we deprecate
emulated prepares, it would make sense to deprecate
PD
>
> > My point is that you are adding 'testing tools' which are only any use
> > to test themselves and not the actual interface? It's creating
> > additional code that has nothing to do with testing that PDO is working
> > cleanly properly across all databases, especially if it does not expect
> >
> My point is that you are adding 'testing tools' which are only any use
> to test themselves and not the actual interface? It's creating
> additional code that has nothing to do with testing that PDO is working
> cleanly properly across all databases, especially if it does not expect
> a working c
>
> Since PDO is an interface to third party databases this seems totally
> out of place in PHP. Prepared statements are a sensible mechanism for
> for anyone wanting secure access to those database, so what is the point
> of this code.
I don't want to solve for database access. I want to create
>
> I've created an RFC to make it easier to work with emulated prepared
> statements:
> https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation
>
Does anyone have feedback?
On Wed, Oct 19, 2016 at 12:25 PM, Lester Caine wrote:
> On 18/10/16 23:05, Adam Baratz wrote:
> > Please share your feedback. I'm happy to hear thoughts about the
> pdo_dblib
> > example, but the RFC is more about the possibility of driver-specific
> types
> > tha
particular ones.
Thanks,
Adam
your feedback.
I'd like to hone in on one solution for the eventual vote.
Thanks,
Adam
---
[1] http://marc.info/?l=php-internals&m=147638162506291&w=2
I figure it's always easier to discuss proposals alongside real code:
https://github.com/php/php-src/pull/2159
Please let me know what you think, if an RFC would be appropriate, or what.
Thanks,
Adam
On Wed, Oct 12, 2016 at 4:58 AM, Rowan Collins
wrote:
> On 11/10/2016 17:39, Lester Caine wrote:
>
>> The importance of 'null' in relation to SQL data sets is something that
>> PHP seems to push under the carpet a bit. It is essential to the way SQL
>> works and so needs to mirror properly which
>
> I've had a quick look at the bug fix, although I haven't tested it. By
> the looks of it, it seems that the third parameter has become mandatory,
> which to me seems unacceptable.
>
> I would say that the type parameter should have precedence over the
> actual PHP type only when it is explicitl
>
> > Well, I'm pretty sure Postgres won't be affected either way, because
> >>> its type system is such that you can't prepare a query where the types
> of
> >>> parameters can't be decided yet. A query like this simply gives an
> error.
>
> Firebird, oracle and mysql would have exac
>
> >> Well, I'm pretty sure Postgres won't be affected either way, because
> its type system is such that you can't prepare a query where the types of
> parameters can't be decided yet. A query like this simply gives an error.
> >
> > Firebird, oracle and mysql would have exactly the same problem.
e
request. If I don't hear from anyone, I'll keep it to master to give others
the most time to prepare.
Thanks,
Adam
-- Forwarded message --
From: adambar...@php.net
Date: Mon, Oct 3, 2016 at 11:19 AM
Subject: [PHP-BUG] Bug #73234 [NEW]: emulated statements let value dicta
On Tue, Sep 13, 2016 at 10:54 AM, Adam Baratz wrote:
> > I noticed that there's a stale version of a supported package on pecl:
>> > https://pecl.php.net/package/pdo_dblib
>> >
>> > Should this be removed to avoid confusion?
>>
>> Alternativ
>
> > I noticed that there's a stale version of a supported package on pecl:
> > https://pecl.php.net/package/pdo_dblib
> >
> > Should this be removed to avoid confusion?
>
> Alternatively a note might be added, as it has been done for
> PECL/domxml, for instance.
>
> Either way, that should also b
Hi,
I noticed that there's a stale version of a supported package on pecl:
https://pecl.php.net/package/pdo_dblib
Should this be removed to avoid confusion?
Thanks,
Adam
> To keep it clean, you can
>
> git checkout master
> git reset --hard origin/master
>
> and same for every branch containing a wrong merge. This will reset every
branch to the state of remote, after that you can repeat the merge clean
way.
Yes, but in this case, I'd already pushed.
will this cause git history issues? Figured it would be better
to check what to do next than to do any preemptive cleanup.
Thanks,
Adam
>
> I've granted you with ext/pdo_dblib karma, it takes a couple of hours to
> propagate, let me know if you need further help.
>
Thanks! Is it also possible to get access to ext/pdo? I needed to add some
conditional logic to get the shared tests running with pdo_dblib, but I can
put up a regular
>
> > One note I missed: it probably goes without saying that I'd like write
> > access to ext/pdo_dblib, but write access to ext/pdo would also help for
> > work on common unit tests and functionality.
>
> +1, Adam have done great work at trying to keep pdo_d
One note I missed: it probably goes without saying that I'd like write
access to ext/pdo_dblib, but write access to ext/pdo would also help for
work on common unit tests and functionality.
On Tue, Aug 30, 2016 at 4:00 PM, Adam Baratz wrote:
> Maintain pdo_dblib extension.
>
&
> Do you already have a git account? If not, you should request one on
http://php.net/git-php.php.
Didn't know about that. Just did, thanks.
Maintain pdo_dblib extension.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
te so it can be run more reliably/consistently across environments. I'd
be happy to push through the bugs queue shortly and see if it can be
cleaned up.
Thanks,
Adam
this. It would help to know
more about what's expected. In particular, when PRs poke at broader design
questions with the extension, what's the maintainer's role? One example:
https://github.com/php/php-src/pull/2017
Thanks,
Adam
there would be
value in getting phpize to produce some of this. Am I right in guessing
that other people want to do things like this?
Thanks,
Adam
1 - 100 of 699 matches
Mail list logo
