I guess leaving nr. 3 out would be fine. What would he the proper path to do this in erlang? Just writing some erlang example code and opening issues?
Sent from my iPhone > On 7 Apr 2022, at 06:46, José Valim <[email protected]> wrote: > > > All three of them would require changes to Erlang and I would love for > someone to chase this path. 2 sounds doable with EEP 54 but 1 would > definitely require more discussion. > > I am not sure about 3. binwrite pretty much means "I know what I am doing" > and we should allow the user to write whatever they want as is. > >> On Thu, Apr 7, 2022 at 7:25 AM Jonatan Männchen <[email protected]> wrote: >> Thanks, that solved my specific issue. I still think that some improvements >> are needed. >> >> Looking at the code for CaptureIO, I think those changes should be made >> directly in the StringIO / IO modules and not specifically for CaptureIO. >> >> The following things are not great today IMHO: >> The encoding that lets everything through is called latin1. I think we >> should introduce & properly document a new encoding called something like >> raw_binary. It would work exactly the same though. >> IO.write with invalid characters into an io device with any encoding should >> have a better error message. (Something like "<<222>> is not a valid unicode >> string. Provide `encoding: :raw_binary` when opening the io device") >> IO.binwrite with invalid characters into an encoding: :unicode io device >> should probably at least warn if invalid characters are passed. >> This would something like this in the form of a test: >> https://gist.github.com/maennchen/f428360a71d23a323538d9b7d51e638b >> >>> On Wednesday, April 6, 2022 at 9:29:12 PM UTC+2 Wojtek Mach wrote: >>> > Additionally, it would be good if there was a proper error for invalid >>> > characters instead of the currently raised ArgumentError. >>> >>> Yeah the error is pretty bad: >>> >>> IO.puts(<<222>>) >>> ** (ArgumentError) errors were found at the given arguments: unknown error: >>> put_chars >>> >>> It is slightly more informative when used inside capture io though: >>> >>> assert capture_io(fn -> >>> IO.puts(<<222>>) >>> end) == <<222>> >>> ** (ArgumentError) errors were found at the given arguments: unknown error: >>> {put_chars,unicode,[<<"Þ">>,10]} >>> >>> We get error because stdio is with unicode encoding: >>> >>> iex> :io.getopts(:standard_io)[:encoding] >>> :unicode >>> >>> and we're writing <<222>> which isn't unicode. >>> >>> For writing in raw mode, use IO.binwrite. This and the previously mentioned >>> :encoding option will make the following test succeed: >>> >>> assert capture_io([encoding: :latin1], fn -> >>> IO.binwrite(<<222>>) >>> end) == <<222>> >>> >>> On April 6, 2022, "maennchen.ch" <[email protected]> wrote: >>> That unfortunately gives me the same result. >>> >>>> On Wednesday, April 6, 2022 at 6:57:35 PM UTC+1 Wojtek Mach wrote: >>>> I believe capture_io(encoding: :latin1, fun) should do the trick, can you >>>> check? >>>> >>>> On April 6, 2022, "maennchen.ch" <[email protected]> wrote: >>>> Hi everyone, >>>> >>>> Background >>>> >>>> While developing tests for a mix task, that returns non UTF8 binaries into >>>> STDOUT (building block to be piped into a file / pipe), I found that >>>> ExUnit.CaptureIO can only handle UTF8 and Latin1. >>>> >>>> Example Test that does not work: >>>> https://gist.github.com/maennchen/16d411eeda3255fa3d3152fe9d836a82 >>>> >>>> Proposal >>>> >>>> For testing this use case, it would be good if any raw binary would also >>>> be passed through. (Maybe via option "encoding: :raw_binary") >>>> >>>> Additionally, it would be good if there was a proper error for invalid >>>> characters instead of the currently raised ArgumentError. >>>> >>>> Real World Example >>>> >>>> Here is a real test, that would be made possible by this change: >>>> https://github.com/elixir-gettext/expo/blob/9048fe242830614f6d4235cbd345de844693f28a/test/mix/tasks/expo.msgfmt_test.exs#L18 >>>> >>>> PR >>>> >>>> I'm happy to provide a PR for this as well. >>>> >>>> Thanks & Kind Regards, >>>> Jonatan >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "elixir-lang-core" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/elixir-lang-core/e35e97cf-00d6-422e-b3c1-ec508ff1e36fn%40googlegroups.com. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "elixir-lang-core" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/9e817fc9-6f61-4476-bb27-c062ed6167fan%40googlegroups.com. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/f2816480-4d91-4576-9241-3bdc9351a920n%40googlegroups.com. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/RR7nbeHsluQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KdzYkX%3DL%3D3%3DYHSJk4R8iq1%3Dbe9262Fg54eX1yLrx-c9g%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/F3C0BE5C-EC1A-4574-8586-7FC5E7AFD39A%40maennchen.ch.
