| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
semver-major because of the docs-only deprecation. |
Sorry, something went wrong.
There was a problem hiding this comment.
There are two spaces in «the memory» for some reason.
Sorry, something went wrong.
|
Hm. Overall looks good, but I'm not sure on the exact syntax. It seems to me that Buffer.allocUnsafe(10, true) is not very clear to someone who does not use (or see) it often. Pehaps adding an options argument would be better? E.g. Buffer.allocUnsafe(10, {pooled: false})? |
Sorry, something went wrong.
|
The object would make sense if we'd ever expect there to be additional possible options. I don't think that's the case. Also, part of the point for adding it as a second parameter was to avoid making things unnecessarily complex for this case (as opposed to adding a new function, etc). I know it's less obvious what is happening, but I think it's appropriate here. But that's just me. What do you think @trevnorris ? |
Sorry, something went wrong.
Sorry, something went wrong.
|
Could also have Buffer.allocUnsafe(n, kUnpooled) as a bitwise flag. :P Without writing any benchmarks, I think passing in the extra object isn't going to add much if any noticeable overhead. Though after watching the Buffer API evolve over the last several years I can't foresee needing to pass any other options. Possibly use the boolean, but also strict check that the argument is a boolean instead of coercing it. |
Sorry, something went wrong.
There was a problem hiding this comment.
something like:
if (unpooled !== undefined && typeof unpooled !== 'boolean')
throw new TypeError('unpooled must be a boolean');
Sorry, something went wrong.
|
@trevnorris ... added the additional type check. |
Sorry, something went wrong.
|
Thanks. I'm cool with the new API, but would also like other's opinions. |
Sorry, something went wrong.
|
@nodejs/ctc ... please weigh in :-) |
Sorry, something went wrong.
|
@nodejs/collaborators ... |
Sorry, something went wrong.
|
I think I'd prefer the bitwise flag idea. Pros:
Cons:
I'm not so for adding [, true] to the buffer apis, it's not very easy to tell what that is. Also, I can't imagine many people are actually using SlowBuffer. @ChALkeR could you test npm to try to see who might be using this? |
Sorry, something went wrong.
|
A bitwise flag sounds like a good compromise on this. I can't imagine that we'd actually add any more flags to this but you never know. |
Sorry, something went wrong.
|
@Fishrock123 @trevnorris ... switched to using a Bitwise field. PTAL |
Sorry, something went wrong.
|
This approach looks better to me =).
Using SlowBuffer or Buffer.allocUnsafe? The former won't be affected by this, and the latter isn't used yet because it just recently landed to master. SlowBuffer( usage: https://gist.github.com/ChALkeR/43f3376f46b3d71e1e62ef37f643fb06 Note that this doesn't include on purpose pure instanceof SlowBuffer (which is broken btw) and SlowBuffer method redifinitions (there were some, copied in various modules, they mostly add some methods from Buffer to SlowBuffer for older Node.js versions). Note: mocha has its own SlowBuffer that is not related to Node.js SlowBuffer, ignore that match. It affects many lines in the grep result. |
Sorry, something went wrong.
|
Rebased, squashed. New CI: https://ci.nodejs.org/job/node-test-pull-request/2131/ |
Sorry, something went wrong.
|
@trevnorris @Fishrock123 @ChALkeR ... ping |
Sorry, something went wrong.
There was a problem hiding this comment.
It looks like this is missing the
if (size > 0)
flags[kNoZeroFill] = 1;in the createBuffer case.
Sorry, something went wrong.
There was a problem hiding this comment.
Good catch.
Sorry, something went wrong.
PR-URL: #5833 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Sorry, something went wrong.
Aligns the functionality of SlowBuffer with the new Buffer constructor API. Next step is to docs-only deprecate SlowBuffer. Replace the internal uses of SlowBuffer with `Buffer.allocUnsafeSlow(size)` PR-URL: nodejs#5833 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
With the addition of `Buffer.allocUnsafeSlow(size)` `SlowBuffer` can be deprecated... but docs-only for now. PR-URL: nodejs#5833 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
PR-URL: nodejs#5833 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Aligns the functionality of SlowBuffer with the new Buffer constructor API. Next step is to docs-only deprecate SlowBuffer. Replace the internal uses of SlowBuffer with `Buffer.allocUnsafeSlow(size)` PR-URL: #5833 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
With the addition of `Buffer.allocUnsafeSlow(size)` `SlowBuffer` can be deprecated... but docs-only for now. PR-URL: #5833 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
PR-URL: #5833 Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
|
Note that this change wasn't backported to 5.x, unlike all the other new Buffer API methods, which were backported in #5763. |
Sorry, something went wrong.
Sorry, something went wrong.
This backports the new `Buffer.alloc()`, `Buffer.allocUnsafe()`, `Buffer.from()`, and `Buffer.allocUnsafeSlow()` APIs for v4. Some backported tests are disabled, but those are not related to the new API. Note that `Buffer.from(arrayBuffer[, byteOffset [, length]])` is not supported in v4.x, only `Buffer.from(arrayBuffer)` is. Refs: nodejs#4682 Refs: nodejs#5833 Refs: nodejs#7475 PR-URL: nodejs#7562 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
This backports the new `Buffer.alloc()`, `Buffer.allocUnsafe()`, `Buffer.from()`, and `Buffer.allocUnsafeSlow()` APIs for v4. Some backported tests are disabled, but those are not related to the new API. Note that `Buffer.from(arrayBuffer[, byteOffset [, length]])` is not supported in v4.x, only `Buffer.from(arrayBuffer)` is. Refs: #4682 Refs: #5833 Refs: #7475 PR-URL: #7562 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
This backports the new `Buffer.alloc()`, `Buffer.allocUnsafe()`, `Buffer.from()`, and `Buffer.allocUnsafeSlow()` APIs for v4. Some backported tests are disabled, but those are not related to the new API. Note that `Buffer.from(arrayBuffer[, byteOffset [, length]])` is not supported in v4.x, only `Buffer.from(arrayBuffer)` is. Refs: #4682 Refs: #5833 Refs: #7475 PR-URL: #7562 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
This backports the new `Buffer.alloc()`, `Buffer.allocUnsafe()`, `Buffer.from()`, and `Buffer.allocUnsafeSlow()` APIs for v4. Some backported tests are disabled, but those are not related to the new API. Note that `Buffer.from(arrayBuffer[, byteOffset [, length]])` is not supported in v4.x, only `Buffer.from(arrayBuffer)` is. Refs: #4682 Refs: #5833 Refs: #7475 PR-URL: #7562 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
This backports the new `Buffer.alloc()`, `Buffer.allocUnsafe()`, `Buffer.from()`, and `Buffer.allocUnsafeSlow()` APIs for v4. Some backported tests are disabled, but those are not related to the new API. Note that `Buffer.from(arrayBuffer[, byteOffset [, length]])` is not supported in v4.x, only `Buffer.from(arrayBuffer)` is. Refs: #4682 Refs: #5833 Refs: #7475 PR-URL: #7562 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
This backports the new `Buffer.alloc()`, `Buffer.allocUnsafe()`, `Buffer.from()`, and `Buffer.allocUnsafeSlow()` APIs for v4. Some backported tests are disabled, but those are not related to the new API. Note that `Buffer.from(arrayBuffer[, byteOffset [, length]])` is not supported in v4.x, only `Buffer.from(arrayBuffer)` is. Refs: #4682 Refs: #5833 Refs: #7475 PR-URL: #7562 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
| Back | FazBrowse Home | New Git URL |
Pull Request check-list
this change (including linting)?
test (or a benchmark) included?
existing APIs, or introduces new ones)?
Affected core subsystem(s)
buffer
Description of change
Essentially, this aligns the functionality of SlowBuffer with the new constructor API
Refs: #5799
/cc @ChALkeR @trevnorris