AV
{-# NOINLINE foo #-}
foo = unsafePerformIO $ do
lookupEnv "PROJECT_UNOPTIMIZED" >>= return . maybe (fooOptimized) (const fooUnoptimized)Size: a a a
2020 December 10
к
Спека там, по слухам, ужасная
тем интереснее задача
TZ
а в хаскеле есть хоть что-нибудь не 0.*, интересно?
Megaparsec?
AV
{-# NOINLINE foo #-}
foo = unsafePerformIO $ do
lookupEnv "PROJECT_UNOPTIMIZED" >>= return . maybe (fooOptimized) (const fooUnoptimized)(никогда так не делайте)
AV
Не просто DI, а полноценный Spring или какой-нибудь Castle Windsor с резолвом на основе текстового конфига.
Мне кажется, можно попробовать соорудить что-то на основе синглтонов, чтобы в зависимости от нужного внешнего условия резолвился тот или иной тип, для которого уже резолвился бы инстанс тайпкласса с нужным алгоритмом.
Мне кажется, можно попробовать соорудить что-то на основе синглтонов, чтобы в зависимости от нужного внешнего условия резолвился тот или иной тип, для которого уже резолвился бы инстанс тайпкласса с нужным алгоритмом.
Мне скорее кажется, что реальнее частично типизированный реестр делать и через него инициализироваться
к
{-# NOINLINE foo #-}
foo = unsafePerformIO $ do
lookupEnv "PROJECT_UNOPTIMIZED" >>= return . maybe (fooOptimized) (const fooUnoptimized)почему, норм
AV
У меня 4-5 таких штук в проекте, обычно для всяких хаков, которые иногда включать надо
AV
Типа, включать не совсем корректный fallback механизм на случай если внешний сервис сдох, автоматом такое не хочется делать
AV
Мне скорее кажется, что реальнее частично типизированный реестр делать и через него инициализироваться
Я об этом начал задумываться в контексте использования manager-ов в http client. минио и т.д.
AV
Т.е. например хочется описать несколько менеджеров с настройками стандартными своим user-agent, таймаутами. И потом цеплять в разные сервисы и тоже самое с сервисами работы файлов; в итоге вылезает куча зависимостей, которые бы не очень хотелось решать в коде
ЮБ
Мне скорее кажется, что реальнее частично типизированный реестр делать и через него инициализироваться
С реестром можно очень много чего огрести. Я писал подобный реестр на тайпскрипте для фронтовых модулей — по сути, собирал несколько ридеров в один большой с соответствующим вайденингом типов. Еще то счастье, по правде говоря.
AV
Не очень понимаю зачем тут собирать много ридеров, грубо говоря это будет большой TypeRepMap
AV
Ну и это только на момент resolve зависит после запуска программы уже остаются только обычные структуры
YS
вопрос
собираю приложение
почему так?
собираю приложение
cabal build app
потом ставлюcabal install app:exe:myapp --install-method=copy --installdir=/path/to/dir --overwrite-policy=always -v
ожидаю что возьмёт только что собранное, но (включил -v) смотрю по логам - пересобирает зановопочему так?
MK
потому что пошёл нафиг вот почему
MK
этож кабал
YS
это я уже понял!
LO
должен перелинковать как минимум
YS
я уже смирился почти с этим
LO
из-за RUNPATH