Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add string/binary type color to ByteStream #12897

Merged
merged 19 commits into from
May 20, 2024

Conversation

devyn
Copy link
Contributor

@devyn devyn commented May 17, 2024

Description

This PR allows byte streams to optionally be colored as being specifically binary or string data, which guarantees that they'll be converted to Binary or String appropriately on into_value(), making them compatible with Type guarantees. This makes them significantly more broadly usable for command input and output.

There is still an Unknown type for byte streams coming from external commands, which uses the same behavior as we previously did where it's a string if it's UTF-8.

A small number of commands were updated to take advantage of this, just to prove the point. I will be adding more after this merges.

User-Facing Changes

  • New types in describe: string (stream), binary (stream)
  • These commands now return a stream if their input was a stream:
    • into binary
    • into string
    • bytes collect
    • str join
    • first (binary)
    • last (binary)
    • take (binary)
    • skip (binary)
  • Streams that are explicitly binary colored will print as a streaming hexdump
    • example:
      1.. | each { into binary } | bytes collect

Tests + Formatting

I've added some tests to cover it at a basic level, and it doesn't break anything existing, but I do think more would be nice. Some of those will come when I modify more commands to stream.

After Submitting

There are a few things I'm not quite satisfied with:

  • String trimming behavior. We automatically trim newlines from streams from external commands, but I don't think we should do this with internal commands. If I call a command that happens to turn my string into a stream, I don't want the newline to suddenly disappear. I changed this to specifically do it only on Child and File, but I don't know if this is quite right, and maybe we should bring back the old flag for trim_end_newline
  • Known binary always resulting in a hexdump. It would be nice to have a print --raw, so that we can put binary data on stdout explicitly if we want to. This PR doesn't change how external commands work though - they still dump straight to stdout.

Otherwise, here's the normal checklist:

  • release notes
  • docs update for plugin protocol changes (added type field)

devyn added 5 commits May 17, 2024 08:24
squashed commits:

----

Be more strict about stream type, and always require it

----

make type non-Option, because None doesn't look very clear

----

also clean up tee a bunch

----

Add helpers for mapping between ByteStream and ListStream

----

do some cleanup and rethink how to map PipelineData into ByteStream

----

make describe output for byte streams mirror that of list streams

----

Temporary fix: print binary streams by collecting them through
pretty_hex() first

----

fix `describe -n` on byte streams to not drain

----

streaming pretty hex output for binary streams

----

Don't pipe byte streams through `table` when passing to external
commands

----

remove extraneous write

----

Replace the `VecDeque` with a `Cursor<Vec<u8>>`

Since the vec is always empty when generating anyway, there's no need
for a `VecDeque`. That would be better if we wanted to write stuff while
there is still data. The `Cursor<Vec<u8>>` is less complex in
implementation and should be a bit faster

----

preserve stream for `into binary`, `into string`

----

make sure `PipelineData::map` respects byte stream type

----

Make the Values iterator buffering more sensible

Will return whatever buffers it gets, tries to assemble correct UTF-8
for strings. No line-based buffering here, use `lines` for that if you
need it

----

fix `lines`, and change `Lines` to return strings without line ending

----

fix something broken by the merge

----

don't need to take line endings off in Lines because ByteLines already
does it

fixup 1
test str join
fix `join`: iter should not have been strict

fixup 2

test bytes collect
@devyn devyn requested a review from IanManske May 17, 2024 16:15
crates/nu-protocol/src/pipeline/pipeline_data.rs Outdated Show resolved Hide resolved
crates/nu-protocol/src/pipeline/byte_stream.rs Outdated Show resolved Hide resolved
crates/nu-engine/src/command_prelude.rs Show resolved Hide resolved
crates/nu-protocol/src/io/buffers.rs Outdated Show resolved Hide resolved
crates/nu-protocol/src/io/values/mod.rs Outdated Show resolved Hide resolved
crates/nu-protocol/src/pipeline/byte_stream.rs Outdated Show resolved Hide resolved
crates/nu-command/src/viewers/table.rs Show resolved Hide resolved
crates/nu-command/src/filters/tee.rs Outdated Show resolved Hide resolved
crates/nu-protocol/src/pipeline/byte_stream.rs Outdated Show resolved Hide resolved
crates/nu-protocol/src/pipeline/byte_stream.rs Outdated Show resolved Hide resolved
@IanManske
Copy link
Member

IanManske commented May 17, 2024

Thanks @devyn, it looks good for the most part. Looks like there's some merge/rebase artifacts, sorry for all the force pushes lol.

@IanManske IanManske added pr:plugins This PR is related to plugins pr:breaking-change This PR implies a change affecting users and has to be noted in the release notes pr:commands This PR changes our commands in some way labels May 17, 2024
@fdncred
Copy link
Collaborator

fdncred commented May 18, 2024

Does this not work just because all the commands haven't been ported yet?

 open README.md | into binary | first 100
Error: nu::shell::only_supports_this_input_type

  × Input type not supported.
   ╭─[entry #2:1:1]
 1  open README.md | into binary | first 100
   · ──┬─                           ──┬──
   ·                                 ╰── only list, binary or range input data is supported
   ·   ╰── input type: byte stream
   ╰────

Co-authored-by: Ian Manske <ian.manske@pm.me>
@devyn
Copy link
Contributor Author

devyn commented May 18, 2024

No worries Ian.

@fdncred - since a ByteStream should behave the same way, I think I should fix that here. I don't want to cause anything to break in this PR, it should really just make things stream but otherwise work the same way they did before

@fdncred
Copy link
Collaborator

fdncred commented May 18, 2024

@fdncred - since a ByteStream should behave the same way, I think I should fix that here. I don't want to cause anything to break in this PR, it should really just make things stream but otherwise work the same way they did before

sounds good to me. I just use first, last, skip, take quite a bit with binaries and into binary so I'd hope it would keep working.

@devyn
Copy link
Contributor Author

devyn commented May 19, 2024

@fdncred

sounds good to me. I just use first, last, skip, take quite a bit with binaries and into binary so I'd hope it would keep working.

so I got first, last, skip, take all working. I also found that skip functionally supported binary even though its type doesn't actually allow for that, so I added that & an example. You'd have to have been using any before for it to work

Anyway it should all be consistent now

@devyn
Copy link
Contributor Author

devyn commented May 19, 2024

@IanManske you mentioned tee before but I didn't quite get to look at what you meant. I had refactored it further and possibly some of the code was old - is it missing anything?

@IanManske
Copy link
Member

IanManske commented May 19, 2024

you mentioned tee before but I didn't quite get to look at what you meant.

I'm not sure either lol, I must have read the code wrong. Anyways, the tee looks much nicer now, thanks!

@IanManske IanManske merged commit c61075e into nushell:main May 20, 2024
15 checks passed
@hustcer hustcer added this to the v0.94.0 milestone May 20, 2024
@devyn devyn deleted the bytestream-streaming-commands branch May 20, 2024 05:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr:breaking-change This PR implies a change affecting users and has to be noted in the release notes pr:commands This PR changes our commands in some way pr:plugins This PR is related to plugins
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants