Use UTF-8 instead of ISO-8859-1 #601

mieszko · 2023-08-15T19:53:04Z

changes BH and BSV parse to use UTF-8 instead of ISO-8859-1
for syntax purposes, Unicode uppercase and titlecase letters are considered to be uppercase letters, while all other code points are considered lowercase
function composition now uses the Unicode ring operator ∘

quark17

Thank you! A few typos and a few serious questions are sprinkled in the code.

I also did a search for "\# and '\# (and with \x) in the source code and found several occurrences, some of which you addressed, but I wonder if you need to consider the others?

CSyntax.hs:        where ppApArg ty = t"\183" <> pPrint d maxPrec ty
CSyntax.hs:        where ppApArg ty = t"\183" <> pPrint d maxPrec ty
CVPrint.hs:        where ppApArg ty = t"\183" <> pvPrint d maxPrec ty
CVPrint.hs:        where ppApArg ty = t"\183" <> pvPrint d maxPrec ty

IExpand.hs:    pPrint d p (T t) = text"\183" <> pPrint d p t

ISyntax.hs:        sep (pPrint d (maxPrec-1) f : map (nest 2 . (text"\183" <>) . pPrint d maxPrec) ts ++ map (nest 2 . pPrint d maxPrec) es)

Id.hs:    "\xbb"-> FInfixr 12 -- https://en.wikipedia.org/wiki/Guillemet or '>>'
Id.hs:    "\xb7"-> FInfixr 13 -- https://en.wikipedia.org/wiki/Interpunct or '.'

bsc.hs:        escChar '$' accum_str = "\044" ++ accum_str

GenWrapUtils.hs:genSuffix = ['\173']

Lex.hs:isSym c | c >= '\x80' = c `elem` ['\162', '\163', '\164', '\165', '\166',
Lex.hs:                                  '\167', '\168', '\169', '\170', '\171',
Lex.hs:                                  '\172', '\173', '\174', '\175', '\176',
Lex.hs:                                  '\177', '\178', '\179', '\180', '\181',
Lex.hs:                                  '\183', '\184', '\185', '\186', '\187',
Lex.hs:                                  '\188', '\189', '\190', '\191', '\215',
Lex.hs:                                  '\247' ]
Lex.hs:--isSym c | c >= '\x80' = isSymbol c

Lex.hs:isIdChar '\'' = True
Lex.hs:isIdChar '\176' = True
Lex.hs:isIdChar '\180' = True

I notice that not only has the handling of text files changed, but also the handling of binary files has changed. Was this necessary because of the change in encoding, or something you cleaned up while you happened to be working in this area? I do see that some functions in FileIOUtil were supporting reading in a file as either text or binary, and thus some of that was made cleaner by having both formats be read in as ByteString, and only at the end do you unpack into [Word8] for binary or decode UTF8 into String for text.

You switched away from hGetContents (in SystemIO) which returns a String, to reading in the file as a ByteString (specifically the lazy version), which is then packed into [Word8] and returned (in place of String).

I was not up to date on current best practices, but I found this page on dealing with binary data in Haskell to be helpful. According to that, normal Haskell String types are lists of 32-bit characters, which is more space than is needed and slows things down. So hopefully we should see an improvement in memory usage?

Switching the symbol for composition is good, because the centerdot is also used by the pretty-printer for displaying type arguments (as you noted when having to update the expected output of dumps in the test suite, and as seen above in the source code lines that print \183).

I see that you updated the headers of the .bo and .ba files, which is good. I assume that the old files will still parse as UTF-8 up through the header, to be able to do that check, right?

We do need to include updates to the documentation in this PR. Presumably the compose operator is documented (or used) in the BH reference guide. I'd guess that it's not mentioned in the Libraries Guide, since that is in BSV. Do we also need to mention the UTF-8 encoding somewhere (like the BSC User Guide)? Any other doc changes that I'm missing?

I'm excited that this will allow users to start writing programs with identifiers in languages that aren't covered by latin1, as seen in your test cases. As I indicated inline, I'm unclear how uppercase and lowercase are handled in other languages and what that means for defining constructors versus variables.

It might also be worth testing the encoding in other places -- for example, in the package and file name?

src/comp/SystemVerilogScanner.lhs

src/comp/SystemVerilogPreprocess.lhs

testsuite/bsc.syntax/bsv05/Latin1Code.bsv

quark17 · 2023-08-16T02:20:08Z

src/comp/FileIOUtil.hs

-readBinFilePath errh pos verb name path =
-    readFilesPath' errh pos True verb [name] path
+                   Bool -> String -> [String] -> IO (Maybe ([Word8], String))
+readBinFilePath errh pos verb name path = maybe Nothing unp <$> readFilesPath' errh pos verb [name] path


It may just be me (as I say below as well), but I might have written this as:

readFilesPath' errh pos verb [name] path >>= fmap unp where unp (bs, name) = (B.unpack bs, name)

or even

>>= fmap (apFst B.unpack)

But this is fine. It just took me a while to untangle it in my head.

However, thinking on it longer, I wonder if you should write this in a style that matches what you're doing in all the other places where you use decode. In this case, you're not decoding, just unpacking; but I wonder if it would be more redable to just write it the same way, with a different function name. (That also maybe suggests that the decode situations might be written more simply by using fmap? Anyway, I have other comments on the decode cases, below.)

i'll resurrect mapFst in Util.hs (currently commented out and only defined for lists) and use your second alternative.

src/comp/Depend.hs

src/comp/BinData.hs

mieszko · 2023-08-16T06:53:24Z

Thank you! A few typos and a few serious questions are sprinkled in the code.

thanks for the near-instant detailed review :)

I also did a search for "\# and '\# (and with \x) in the source code and found several occurrences, some of which you addressed, but I wonder if you need to consider the others?

CSyntax.hs:        where ppApArg ty = t"\183" <> pPrint d maxPrec ty
CSyntax.hs:        where ppApArg ty = t"\183" <> pPrint d maxPrec ty
CVPrint.hs:        where ppApArg ty = t"\183" <> pvPrint d maxPrec ty
CVPrint.hs:        where ppApArg ty = t"\183" <> pvPrint d maxPrec ty

IExpand.hs:    pPrint d p (T t) = text"\183" <> pPrint d p t

ISyntax.hs:        sep (pPrint d (maxPrec-1) f : map (nest 2 . (text"\183" <>) . pPrint d maxPrec) ts ++ map (nest 2 . pPrint d maxPrec) es)

these all print · before a type to indicate type application, right? still produces ·. could you specify what you'd like changed here?

Id.hs: "\xbb"-> FInfixr 12 -- https://en.wikipedia.org/wiki/Guillemet or '>>'
Id.hs: "\xb7"-> FInfixr 13 -- https://en.wikipedia.org/wiki/Interpunct or '.'

this is inside a comment. presumably from ancient days where fixity was actually fixed and not specified via infixr and friends.

bsc.hs: escChar '$' accum_str = "\044" ++ accum_str

i think \044 is , isn't it?

GenWrapUtils.hs:genSuffix = ['\173']

this should be safe — the second unicode block (0x80-0xFF) is the same as the latin1 characters, so you'll get the same code point.

Lex.hs:isSym c | c >= '\x80' = c elem ['\162', '\163', '\164', '\165', '\166',
Lex.hs: '\167', '\168', '\169', '\170', '\171',
Lex.hs: '\172', '\173', '\174', '\175', '\176',
Lex.hs: '\177', '\178', '\179', '\180', '\181',
Lex.hs: '\183', '\184', '\185', '\186', '\187',
Lex.hs: '\188', '\189', '\190', '\191', '\215',
Lex.hs: '\247' ]
Lex.hs:--isSym c | c >= '\x80' = isSymbol c

Lex.hs:isIdChar ''' = True
Lex.hs:isIdChar '\176' = True
Lex.hs:isIdChar '\180' = True

i just added isSymbol to what was there previously to permit unicode symbols (like the compose operator), reason being that not all the characters listed have isSymbol = True.

I notice that not only has the handling of text files changed, but also the handling of binary files has changed. Was this necessary because of the change in encoding, or something you cleaned up while you happened to be working in this area?

the binary stuff assumed that one character is always one byte, which is not the case in utf8. so without this change code points that don't fit in one byte would be written (and parsed back as) symbols different from what was in the source. this matters for identifiers for example.

I do see that some functions in FileIOUtil were supporting reading in a file as either text or binary, and thus some of that was made cleaner by having both formats be read in as ByteString, and only at the end do you unpack into [Word8] for binary or decode UTF8 into String for text.
You switched away from hGetContents (in SystemIO) which returns a String, to reading in the file as a ByteString (specifically the lazy version), which is then packed into [Word8] and returned (in place of String).

i had to read a BS anyway to decode utf8, so it made sense to just do that and decode based on bin vs not. i made it lazy b/c it was lazy before, could possibly be that strict is better but i didn't check.

I was not up to date on current best practices, but I found this page on dealing with binary data in Haskell to be helpful. According to that, normal Haskell String types are lists of 32-bit characters, which is more space than is needed and slows things down. So hopefully we should see an improvement in memory usage?

i didn't measure memory usage, and the string-based encoding could well have been lazy enough to be deforested.

in general this whole "binary" thing is not very efficient as-is; at the very least generation could be improved to use Builders or something, and parsing could use idk attoparsec to be easier to read at least. or maybe one could use protobuf; i vaguely recall that there was even something that did this via generics without even needing .proto files?

but i just wanted to get unicode working...

I see that you updated the headers of the .bo and .ba files, which is good. I assume that the old files will still parse as UTF-8 up through the header, to be able to do that check, right?

i don't see why not, decoding would fail only at the first byte sequence that is not valid utf8, and you'd never get there b/c laziness and such.

We do need to include updates to the documentation in this PR. Presumably the compose operator is documented (or used) in the BH reference guide. I'd guess that it's not mentioned in the Libraries Guide, since that is in BSV. Do we also need to mention the UTF-8 encoding somewhere (like the BSC User Guide)? Any other doc changes that I'm missing?

can you point me to where the compose operator appears? i skimmed the docs but couldn't find · being documented. and neither did i find the fact that latin1 was enforced documented anywhere, so i left that alone for now.

I'm excited that this will allow users to start writing programs with identifiers in languages that aren't covered by latin1, as seen in your test cases. As I indicated inline, I'm unclear how uppercase and lowercase are handled in other languages and what that means for defining constructors versus variables.

most scripts not related to ours actually don't make the uppercase/lowercase/titlecase distinctions, and even the latin, greek, cyrillic, etc. alphabets didn't have both uppercase/lowercase forms until relatively recently in history (cf. roman-era inscriptions all over southern and western europe). what that means for constructors vs variables is probably that the distinction is biased to european scripts, or to the fact that programs are commonly written in the latin script (which is just the facts ma'am), depending how generous versus pitchfork-ferous you wish to be.

actually in japanese one might achieve something similar to uppercase by writing something normally written in kanji/hiragana in katakana instead, which kind of has an all-uppercase feeling. but i don't believe most languages have the luxury of multiple phonetically equivalent writing systems in concurrent use like that (maybe serbo-croatian and kazakh get a honourable mention?), and anyway mixing katakana and hiragana in one word like a haskell/bluespec constructor doesn't make sense, so the appropriate distinction here would be all-katakana vs all-kanji/hiragana.

technically the bs spec (which i got from the documentation repo, which i guess is outdated?) only says uppercase and lowercase (as does the haskell spec), but this would preclude e.g., kanji identifiers, so i decided to follow ghc and consider everything that is not uppercase as lowercase. plus surprising things are considered identifier letters in bs, including for example °.

the SV spec specifically specifies ASCII character ranges A-Za-z, but i think it makes sense to match BH here rather than attempt to preserve a false illusion that BSV is actually SV in any meaningful sense.

It might also be worth testing the encoding in other places -- for example, in the package and file name?

good point, will do.

rossc719g · 2023-08-19T01:22:22Z

Just a quick question:

Are we planning to support both the ∘ and · operators as composition? Or just ∘?
The reason I ask, i that it would be nice to use iconv to convert code from latin1 to utf8, but we can only do that if · is supported.

I'm happy with either answer, I just am curious.

rossc719g · 2023-08-19T01:30:28Z

Also, does anyone know a good way to type it on a mac keyboard? · is Option-Shift-9, but I cant seem to get '∘'.

mieszko · 2023-08-19T18:27:37Z

Are we planning to support both the ∘ and · operators as composition? Or just ∘?

i'd like to keep it to one thing, so i guess ∘.

The reason I ask, i that it would be nice to use iconv to convert code from latin1 to utf8, but we can only do that if · is supported.

to convert, this is the black magic i did with the bsc sources:

find . -name '*.bs' -exec perl -CS -p -i -e 's/·/∘/g' \{\} \;

(after doing essentially the same w/ iconv ofc).

mieszko · 2023-08-19T18:33:34Z

Also, does anyone know a good way to type it on a mac keyboard? · is Option-Shift-9, but I cant seem to get '∘'.

hmm good question, i just looked at the us/qwerty layout and none of the circle things seem to be ∘. this is why it would have been nice to make it just ascii . :(

personally the default apple layouts don't meet my needs, so i have a custom keyboard layout (made using ukelele) anyway, and i already had ∘ and other stuff. that is one option you could follow.

you could also switch your keyboard layout to unicode hex input, hold down option, and type 2 2 1 8 (the code point for ∘). contrary to the name, the layout also lets you type in qwerty stuff normally.

i guess another is to locally redefine compose to whatever you like, now that you have tons of potential unicode chars available.

i am somewhat hesitant to choose bs syntax based on whatever is easy to type on a specific platform, since next we'll have complaints from folks on windows, linux, and idk amigaos running on repurposed hardware left over from the nasa mars rover missions.

rossc719g · 2023-08-22T21:27:29Z

Fair enough.

Just curious, why did we settle on ∘ over the exsting ·?
Gotta say, I'm not super thrilled about not being able to type it. :-/

i guess another is to locally redefine compose to whatever you like, now that you have tons of potential unicode chars available.

Do you happen to know a way to force an import from the command line. Adding "import PreludeExtra" to every file is a little icky.

mieszko · 2023-08-25T23:06:02Z

Just curious, why did we settle on ∘ over the exsting ·? Gotta say, I'm not super thrilled about not being able to type it. :-/

The rationale is that this is the usual mathematical compose operator (see the source of all knowledge on this), which in theory would aid clarity.

The really unfortunate thing here is that we can't make . be composition and make it behave like other operators with respect to space. I suppose we could invent another ASCII operator like @ but that might be even more confusing; at least . makes sense from Haskell and has the nice property that it doesn't visually "get in the way" of the other identifiers.

Do you happen to know a way to force an import from the command line. Adding "import PreludeExtra" to every file is a little icky.

You could probably hack something up with preprocessor-level defines, but for my taste that's even more icky...

Personally what I would add an import to every file as you said — it's pretty common to import Util or whatever both in Haskell (to define, idk, mapSnd) and in BS. Or bite the bullet and get my editor to produce ∘.

quark17 · 2023-08-26T04:35:10Z

FYI, I was able to boil down the GHC 9.2 failure to a small example and have submitted it as a GHC issue: https://gitlab.haskell.org/ghc/ghc/-/issues/23891

mieszko · 2023-08-26T15:22:35Z

FYI, I was able to boil down the GHC 9.2 failure to a small example and have submitted it as a GHC issue: https://gitlab.haskell.org/ghc/ghc/-/issues/23891

+10 to house quark for the dedication!

i believe 9.0.2 worked, it was just 9.2.8 that failed, not sure if you want to correct the ghc issue text.

quark17 · 2023-08-31T20:56:11Z

I pushed two commits. The first cleans up a few things:

The Bin instance for String was calling the instance for FString, but that was defined to unwrap the FString and operate on the underlying String; so instead, I moved that functionality to the String instance and made the FString instance be the one to call the String instance.
The Bin instance for Literal was calling the instance for [Char] for writing, but the Char instance for reading. This happens to work because the Char instance also calls the [Char] instance, but I cleaned up the instance for Literal to use Char in both cases.
Remove an extra newline that was introduced
Remove commented-out intermediate version of readBinFilePath

The second commit is my proposal for cleaning up the readFile* functions, to be consistent in style (and reduces the amount of whitespace change from main to keep the change to Git blame minimal). Let me know if I've impacted the efficiency or readability, though, as It's early morning here and I could have made a mistake. Also, feel free to reject or amend this proposed commit.

mieszko · 2023-08-31T21:23:06Z

The Bin instance for String was calling the instance for FString, but that was defined to unwrap the FString and operate on the underlying String; so instead, I moved that functionality to the String instance and made the FString instance be the one to call the String instance.

+1.

The Bin instance for Literal was calling the instance for [Char] for writing, but the Char instance for reading. This happens to work because the Char instance also calls the [Char] instance, but I cleaned up the instance for Literal to use Char in both cases.

+1. iirc i made Char write a string anyway b/c otherwise you don't know how many bytes to read (1–4), but this was def a transparent bug. nice catch.

The second commit is my proposal for cleaning up the readFile* functions, to be consistent in style (and reduces the amount of whitespace change from main to keep the change to Git blame minimal). Let me know if I've impacted the efficiency or readability, though, as It's early morning here and I could have made a mistake. Also, feel free to reject or amend this proposed commit.

looks good to me as well, thank you!

For the purposes of distinguishing variable and constructor / type / package identifiers, Unicode uppercase and titlecase letters are considered uppercase letters; everything else is considered lowercase.

quark17 · 2023-08-31T22:25:12Z

Ok, we are almost there! I have rebased and squashed the commits into just three: use UTF8, change the compose operator, bump the GHC version. All other commits were squashed into the first (use UTF8). I also changed the GHC commit to bump to 9.4.6 (instead of 9.4.5), since that is now available. I've force-pushed this new version of the branch.

Once the CI has finished, I am ready to merge this PR, unless you have any last objections. Thank you!

quark17 · 2023-08-31T22:37:16Z

Oh, some last comments:

We will need to document a number of things, but we can do that separately. Specifically: (1) that the encoding is Unicode; (2) the BH compose operator (although there's no place for that, since the library document comes in only one version, currently for BSV users); (3) any special characters that BSC allows as part of BH identifiers (see next paragraph)?

You noticed that isIdChar in Lex accepts a couple odd characters like degree. The degree symbol can be removed now, because it was once used in the name of autogenerated structs for constructors with multiple fields, but that was changed to _$ in 2009 (see fsTyJoin). Plus, the parser only needs to know about it when reading in the autogenerated code, which we may not need as much since we abolished .bi files? (But the .bi content is stored in .bo files, and I forget if they are smartly stored, or if we naively just wrote the text into the .bo and still use the BH parser to read it back?) If BH doesn't already have an escaping mechanism for identifiers (like BSV), we could add that and use it in pretty printing and then remove the special handling for any that are still needed (and document the remaining ones). But, again, that can be considered separately from this PR.

You removed the explicit package..endpackage, but FYI, BSV files don't need an explicit export statement either, if you're exporting everything. But it doesn't hurt to include export statements in the test cases, and I guess it's also testing non-ASCII characters in export statements, so I left the test examples unchanged.

mieszko · 2023-08-31T23:39:39Z

You noticed that isIdChar in Lex accepts a couple odd characters like degree. The degree symbol can be removed now, because it was once used in the name of autogenerated structs for constructors with multiple fields, but that was changed to _$ in 2009 (see fsTyJoin). Plus, the parser only needs to know about it when reading in the autogenerated code, which we may not need as much since we abolished .bi files? (But the .bi content is stored in .bo files, and I forget if they are smartly stored, or if we naively just wrote the text into the .bo and still use the BH parser to read it back?) If BH doesn't already have an escaping mechanism for identifiers (like BSV), we could add that and use it in pretty printing and then remove the special handling for any that are still needed (and document the remaining ones). But, again, that can be considered separately from this PR.

IIRC I initially accidentally allowed these two characters (° and ´, I think?) to be parsed as symbols in isSym in Lex.hs, but then the testsuite failed somewhere — so I think at least one of them is being used somewhere somehow? I guess we could try removing one at a time and see. (I suppose I could be misremembering, though; it's been a while.)

Either way, it would be nice if this used an encoding that cannot be aliased in .bs or .bsv sources, but investigating that is probably an orthogonal issue to utf8.

mieszko · 2023-09-01T06:48:56Z

BTW, I tried removing ° and ´ from Lex.hs one by one and then both at once and the testsuite passed (ubuntu 22.04). Who knows, maybe it was something like ' or whatever that caused the issue I was remembering...

quark17 · 2023-09-01T10:25:19Z

The checks passed when run with ghc 9.4.5, but when I updated to 9.4.6, there was one failure on macos-13 (a test in testsuite/bsc.typechecker/dontcare is doing a comparison of expected ISyntax and two dictionary let-bindings occurred in swapped order). I am kicking off the CI jobs again, in case it was a fluke. Oh, I see that ghcup offers 9.4.7; I'll update the PR to that and see if it helps. @mieszko if you have macos-13, can you test locally?

mieszko · 2023-09-01T11:21:53Z

@mieszko if you have macos-13, can you test locally?

tested on ventura/arm64 with 9.4.6, all typechecker tests passed. looking at the testcase, i suspect it's a fluke as well, i don't see how any of your changes would cause failure in just that one specific case. (full disclosure: everything passed except a bunch of systemc related tests, but i don't have systemc installed).

quark17 · 2023-09-01T21:27:27Z

The GitHub CI passed for the exact same code but with GHC 9.4.5. Then it failed with GHC 9.4.6 and failed again in the same way when I repeated the jobs. It then passed with 9.4.7. So I think this is probably an issue with GHC 9.4.6. I'm happy to merge the PR now, using 9.4.7. (The GitHub CI for macos-13 is x86_64, which might account for the difference with your local testing. Or maybe it's using a slightly different version of macos-13.)

The failure with 9.4.6 is due to a reordering of ISyntax defs. It's possible that the blame isn't entirely with GHC 9.4.6 and maybe BSC is relying on the stability of some functions (like tsort or hash or something) that it shouldn't. If so, that would be something that was already in BSC and unlikely to be something we introduced here. (We could try an experiment of running the current main branch on GitHub's CI with 9.4.6, to see.) Unless maybe we changed the order in which FStrings are created when reading in .bo files, and that's resulted in the change, but I don't think so. I would guess that BSC is OK and GHC has violated some stability in some way -- but I don't know for sure, and I'm not sure this one can be easily boiled down into an example to report to the GHC folks.

mieszko · 2023-09-01T21:40:50Z

So I think this is probably an issue with GHC 9.4.6. I'm happy to merge the PR now, using 9.4.7.

Yeah, I think that's reasonable.

(The GitHub CI for macos-13 is x86_64, which might account for the difference with your local testing. Or maybe it's using a slightly different version of macos-13.)

Yeah, it feels like some nondeterminism due to some environment settings, doesn't it. Anyway, it looks to me like the nondeterminism here is benign.

quark17 requested changes Aug 16, 2023

View reviewed changes

mieszko pushed a commit to mieszko/bsc that referenced this pull request Aug 16, 2023

changes suggested in @quark17's review of B-Lang-org#601

f423f12

Mieszko added 2 commits September 1, 2023 10:19

Use UTF-8 instead of ISO-8859-1 for all text-like I/O.

f457091

For the purposes of distinguishing variable and constructor / type / package identifiers, Unicode uppercase and titlecase letters are considered uppercase letters; everything else is considered lowercase.

Use the unicode ring operator (∘) for function composition

861d40d

quark17 force-pushed the utf8 branch from c4b1051 to 579b515 Compare August 31, 2023 22:20

Bump GHC version to 9.4.7

11e22b8

quark17 force-pushed the utf8 branch from 579b515 to 11e22b8 Compare September 1, 2023 10:26

quark17 merged commit ebe8877 into B-Lang-org:main Sep 1, 2023
33 checks passed

mieszko deleted the utf8 branch September 2, 2023 01:17

mieszko mentioned this pull request Sep 3, 2023

Disallow ° and ´ in BH identifiers #610

Merged

quark17 mentioned this pull request Oct 14, 2023

Nondeterminism in ISyntax definition order #627

Open

krame505 mentioned this pull request Sep 11, 2024

Add back middle-dot as function composition for backward compatibility #737

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use UTF-8 instead of ISO-8859-1 #601

Use UTF-8 instead of ISO-8859-1 #601

mieszko commented Aug 15, 2023

quark17 left a comment

quark17 Aug 16, 2023

mieszko Aug 16, 2023

mieszko commented Aug 16, 2023

rossc719g commented Aug 19, 2023

rossc719g commented Aug 19, 2023

mieszko commented Aug 19, 2023

mieszko commented Aug 19, 2023

rossc719g commented Aug 22, 2023

mieszko commented Aug 25, 2023

quark17 commented Aug 26, 2023

mieszko commented Aug 26, 2023

quark17 commented Aug 31, 2023

mieszko commented Aug 31, 2023

quark17 commented Aug 31, 2023

quark17 commented Aug 31, 2023

mieszko commented Aug 31, 2023

mieszko commented Sep 1, 2023

quark17 commented Sep 1, 2023

mieszko commented Sep 1, 2023

quark17 commented Sep 1, 2023

mieszko commented Sep 1, 2023

Use UTF-8 instead of ISO-8859-1 #601

Use UTF-8 instead of ISO-8859-1 #601

Conversation

mieszko commented Aug 15, 2023

quark17 left a comment

Choose a reason for hiding this comment

quark17 Aug 16, 2023

Choose a reason for hiding this comment

mieszko Aug 16, 2023

Choose a reason for hiding this comment

mieszko commented Aug 16, 2023

rossc719g commented Aug 19, 2023

rossc719g commented Aug 19, 2023

mieszko commented Aug 19, 2023

mieszko commented Aug 19, 2023

rossc719g commented Aug 22, 2023

mieszko commented Aug 25, 2023

quark17 commented Aug 26, 2023

mieszko commented Aug 26, 2023

quark17 commented Aug 31, 2023

mieszko commented Aug 31, 2023

quark17 commented Aug 31, 2023

quark17 commented Aug 31, 2023

mieszko commented Aug 31, 2023

mieszko commented Sep 1, 2023

quark17 commented Sep 1, 2023

mieszko commented Sep 1, 2023

quark17 commented Sep 1, 2023

mieszko commented Sep 1, 2023