ok, this is completely weird. So I have a test directory that looks like this: $ find ../t/jp ../t/jp ../t/jp/かぐや姫の物語_-_スタジオジブリ|STUDIO_GHIBLI ../t/jp/崖の上のポニョ_-_スタジオジブリ|STUDIO_GHIBLI ../t/jp/コクリコ坂から_-_スタジオジブリ|STUDIO_GHIBLI ../t/jp/思い出のマーニー_-_スタジオジブリ|STUDIO_GHIBLI ../t/jp/千と千尋の神隠し_-_スタジオジブリ|STUDIO_GHIBLI ../t/jp/ゲド戦記_-_スタジオジブリ|STUDIO_GHIBLI ../t/jp/風立ちぬ_-_スタジオジブリ|STUDIO_GHIBLI ../t/jp/借りぐらしのアリエッティ_-_スタジオジブリ|STUDIO_GHIBLI
It shows up like that in a terminal on linux, in file explorer on windows
seems fine
I make a file directory walking tool that I can run. it prints the path and gives me the code points of the strings.
If I run it alone, on either OS, it is fine.
if I run them inside a bazel unit test, then they all come across as code point: �/65533
That would be fine, if that were all that was happening. I've move on with my day and just say bazel unit test framework is weird
but I am getting the same behavior in the HTML generation code (I think. Verifying this)
Well, that was stupid
1. I still don't know what is going on with the unit tests, but whatever
2. I thought String.getBytes() defaulted to utf-8 now, apparently I was wrong
[snowblossomcoin/channels] Issue closed by fireduck64
do the unit tests default to the `C` locale for performance reasons?
and was there something i can try to compile in onto iOS with the gradle or mave thing?
I'm not sure. I the unit tests might be set to something to avoid destroying terminals when things go wrong or something.
SnowBlossomClient would be a good choice, it will include all the crypto bits but won't include the rocksdb (or won't need it, even if it is actually in the jar)
i just need something i can put into the maven or gradle config to see if it goes through the ahead of time compiler or not
i'd assume something needs to be on a public repository to be installable that way
i'm trying to get a white blank screen app going as a feasibility study