I’ve never done a PR to OTP so far. I’ll check it out and ping back here for updates.
Sent from my iPhone > On 7 Apr 2022, at 07:09, José Valim <jose.va...@dashbit.co> wrote: > > > I would start with 2 by submitting a PR to Erlang/OTP and then access their > appetite from there. :) > >> On Thu, Apr 7, 2022 at 8:03 AM Jonatan Männchen <jona...@maennchen.ch> wrote: >> 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 <jose.va...@dashbit.co> 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 <jona...@maennchen.ch> >>>> 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" <jon...@maennchen.ch> 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" <jon...@maennchen.ch> 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 elixir-lang-co...@googlegroups.com. >>>>>> 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 elixir-lang-co...@googlegroups.com. >>>>> 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 elixir-lang-core+unsubscr...@googlegroups.com. >>>> 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 >>> elixir-lang-core+unsubscr...@googlegroups.com. >>> 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 elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/F3C0BE5C-EC1A-4574-8586-7FC5E7AFD39A%40maennchen.ch. > > -- > 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 > elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BSqS4j-VRG_aBfSfs3uc3c0Q_m3svGTKS%2Bw2OR5aO_rg%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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/08729069-5CF7-4400-BAC3-A93E1DA43B1A%40maennchen.ch.
