IRC channel logs
2023-05-05.log
back to list of logs
<lloda>shouldn't make_custom_binary_input_port use %default-port-encoding instead of sym_ISO_8859_1 <lloda>same with all the other make*port functions there i suppose <civodul>lloda: hi! ISO-8859-1 is what's used to denote "binary" ports <lloda>that doesn't make sense to me, you use these ports to read text just the same <lloda>for example in guile-zlib, if you get a port with make-with-gzipped-whatever, you get an ascii port regardless of whether the original port was utf-8 and regardless of whether the default port was utf-8 <lloda>if you do a binary read the encoding doesn't matter, does it? <flatwhatson>there's not really a binary read? just reading into string or bytevector <flatwhatson>so if you have a "binary" port, you're reading into a string of 8-bit chars <flatwhatson>reading into a bytevector is always "binary" and ignores the encoding <flatwhatson>so really there is no difference between text or binary ports except the encoding <flatwhatson>so if you ask for a binary port with encoding other than ISO-8859-1 you actually have a textual port <lloda>there's no make-custom-input/output-port proc, so make-custom-binary-input/output-port gets used for either. Idk why -binary- is in the name tbh. Whoever uses the port to read binary wouldn't care and if you use it to read text then %default-port-encoding is much more likely to be right than ascii <flatwhatson>maybe the solution is to add make-custom-input/output-port which behave as you expect <lloda>in the meantime i'll patch guile-zlib to pass along the encoding <wingo>i think binary is in the name because r6rs has this split between binary and textual ports that we don't have <sneek>Welcome back wingo, you have 1 message! <wingo>lloda: civodul: i think i agree, %default-port-encoding is probably the right thing; probably a guile 3.2 change tho because of back-compat <wingo>the argument being, that if you really want to interact with the port in a binary way, you are using put-u8, get-bytevector, etc which don't pay attention to encoding <wingo>encoding is only used when using text interfaces on the port, whether read or write. and for those, the default port encoding is probably right, much more so than latin1 <wingo>fibers is finding gnarly guile bugs these days <civodul>wingo: re %default-port-encoding, yeah, i guess you're right <civodul>lloda: re guile-zlib, i guess you can set-port-encoding! in the meantime? <lloda>i think the same goes for other port creation routines like call-with-output-bytevector etc. Those should all use %default-port-encoding <lloda>root of that would be make_bytevector_input/output_port <civodul>lloda: neat! i wonder if we should really fix it in each library <civodul>(i thought you were talking about a patch for Guile, apologies for misunderstanding!) <civodul>i would set-port-encoding! in the application as a temporary workaround <civodul>+ fix Guile as wingo suggested (for 3.2) <lloda>i mean we're still on 3.0 so i wasn't sure how that should go <lloda>like should we branch to 3.1 first? <civodul>yeah, though we don't have anything to put in there apart from that <lloda>wdty about make_bytevector_*_port? <civodul>as the place to change the encoding? <civodul>i haven't checked, we should do the same as for the other port types <lloda>to default to %default-input-port instead of iso-8* <lloda>i think for guile-zlib it might still make sense to inherit the encoding instead of relying on the default, since it's making one port from another. Not sure <lloda>anyway i'll send a patch to guile-devel <civodul>ah yes, inheriting the encoding of the original port, that makes sense <RhodiumToad>soo... is there any chance that the SSAX upstream bug fix will be incorporated into guile any time soon?