karky7のブログ

2019年7月28日日曜日

mysql-workbenchのロケールエラー

久しぶりにmysql-workbenchを使おうと思って起動したら、ファイル開こうとすると落ちる。

(mysql-workbench-bin:1061): glibmm-ERROR **: 05:41:45.709:
unhandled exception (type std::exception) in signal handler:
what: locale::facet::_S_create_c_locale name not valid

calimakvo ~ #

ちょっと調べて見たところ、落ちてる場所は、

cuomo@calimakvo ~ $ nm -D --demangle /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libstdc++.so | grep std::locale::facet::_S_create_c_locale
00000000000d99b0 T std::locale::facet::_S_create_c_locale(__locale_struct*&, char const*, __locale_struct*)
cuomo@calimakvo ~ $

なんとlibstdc++のなかではないですか、でそこのコード

void
locale::facet::_S_create_c_locale(__c_locale& __cloc, const char* __s,
                  __c_locale __old)
{
  __cloc = __newlocale(1 << LC_ALL, __s, __old);
  if (!__cloc)
    {
  // This named locale is not supported by the underlying OS.
  __throw_runtime_error(__N("locale::facet::_S_create_c_locale "
                "name not valid"));
    }
}

細かいことは分かりませんが、__clocにロケールカテゴリオブジェクトを返せないようなので、こういうのは、英語のロケールまわりをいじくるのが「定説です」 ...自信はさほどありません

そこで、localeを確認してみる

calimakvo ~ # locale -a
C
C.utf8
POSIX
ja_JP
ja_JP.eucjp
ja_JP.utf8

たぶん、この中のロケールでは足りない可能性があるので、さらに追加してみた

/etc/locale.gen を修正し以下のコメントを外す

en_US.UTF-8 UTF-8

locale-gen再実行

calimakvo ~ # locale-gen
 * Generating 6 locales (this might take a while) with 8 jobs
 *  (1/6) Generating en_US.ISO-8859-1 ...                     [ ok ]
 *  (3/6) Generating ja_JP.EUC-JP ...                         [ ok ]
 *  (4/6) Generating ja_JP.EUC-JP ...                         [ ok ]
 *  (5/6) Generating ja_JP.UTF-8 ...                          [ ok ]
 *  (6/6) Generating C.UTF-8 ...                              [ ok ]
 *  (2/6) Generating en_US.UTF-8 ...                          [ ok ]
 * Generation complete
 * Adding locales to archive ...                              [ ok ]

めでたくmysql-workbenchが利用可能になりました、まぁ、「言語はローケールは母国語と英語は設定しときなさい」ということらしいです。

2019年5月14日火曜日

YesodのFileInfoにハマった

Yesodでアップロードファイルを扱うのにFileInfo型を使うんだけどこれ

data FileInfo = FileInfo {
    fileName :: !Text,
    fileContentType :: !Text,
    fileSourceRaw :: !(ConduitT () ByteString (ResourceT IO) ()),
    fileMove :: !(FilePath -> IO ())
}

これのfileSourceRawなんだが、こうやってとってみると[ByteString]がでてくる

bss <- sourceToList $ fileSource finfo

でたまたまこれをbase64化すればhtmlのimgタグで見れるかとおもいこうやってTextへ変換してhamletテンプレートに出力してみた

import qualified Data.ByteString.Base64 as B64
import qualified Data.ByteString.Char8 as C
import qualified Data.Text as T
import Data.Text.Encoding (decodeUtf8)
...
byteString2Base64 :: [ByteString] -> T.Text
byteString2Base64 = decodeUtf8 . B64.encode . C.unwords

これで吐かれたテキストを

<img src="data:#{contentType};base64,#{b64img}" class="img-fluid mx-auto d-block" alt="">

b64imgにbase64のTextが流れてくが、これが甘い

これだと出力される画像が途中で腐ってしまう、しばらくハマる...よくよく調べてみると、こんなのあった

fileSourceByteString!!

Yesod.Core.Handlerで定義されテイルではないですか、、、やりたかったことそのまんま。

気になったので実装みてみたら....

fileSourceByteString :: MonadResource m => FileInfo -> m S.ByteString
fileSourceByteString fileInfo = runConduit (L.toStrict <$> (fileSource fileInfo .| sinkLazy))

なんか、CombinatorsでつなげてLazyをStrictに直してるようにしか見えないけど、sourceToListを使った方法との違いが分からない。

まぁ結果オーライとします。