Там сотни аллокаций.

Таки откуда

Не забыл ли ты про ea

Что он может нахер все это выкинуть

Не забыл ли ты про ea

Расскажи

ктонибудь, кто читал статью De Goes-а про [Onion](http://degoes.net/articles/modern-fp-part-2) разобрался как там подразумевается имплементировать интерпретаторы которые должны выражатся в терминах другого интерпретатора ? вот это все: val bankingLogging : BankingF ~< Halt LoggingF val bankingProtocol : BankingF ~< ProtocolF val protocolSocket : ProtocolF ~< SocketF val loggingFile : LoggingF ~< FileF val execFile : FileF ~> IO val execSocket : SocketF ~> IO

я не читал, но подозреваю, что очередная бесплатная раздача фри монад. Free monads are not free. Мне кажется, что хорошая идея - это написать монад-трансформер, который позволяте комбинировать future, option и делать из них на выходе какой-нибудь spray Response. Это позволит потом в одном читабельном for comprehension использовать любые бизнес-функции и не перегонять их в toFutureOption orError “bla-bla-error”. А использовать монад-трансформеры для бизнес-логики - это очень долго как писать, так и после тебя читать.

Расскажи

Да я плохой рассказчик, гуглится escape analysis

Таки откуда

Там такая задача. Нужно строить большие-большие деревья.

Да я плохой рассказчик, гуглится escape analysis

Не, не прокатит. Там не временный мусор.

мне кажется проще ручками назначить очистку) вполне нормальное явление)

да и контролировать проще, можно сделать менеджера памяти простенького, который и по обьему ограничить и по времени

я не читал, но подозреваю, что очередная бесплатная раздача фри монад. Free monads are not free. Мне кажется, что хорошая идея - это написать монад-трансформер, который позволяте комбинировать future, option и делать из них на выходе какой-нибудь spray Response. Это позволит потом в одном читабельном for comprehension использовать любые бизнес-функции и не перегонять их в toFutureOption orError “bla-bla-error”. А использовать монад-трансформеры для бизнес-логики - это очень долго как писать, так и после тебя читать.

ну да, и он там делал еще доклад недавно free vs monad transformers и у него трансформеры победили но хотелось бы понять полностью его идею все равно

Не, не прокатит. Там не временный мусор.

Ты все дерево наружу выкидываешь?)

Ты все дерево наружу выкидываешь?)

Да.

@fomkin можно конечно кэшировать дерево, но тебе за память не страшно?)

в том виде как ты описываешь задачу - это невозможно сделать

@fomkin и как часто одно и тоже дерево считается

Там сотни аллокаций.

сотни аллокаций - это немного. как же иммутаблы? ))) они постоянно аллокируют)) вот миллионы микроаллокаций в секунды - это да)

@fomkin можно конечно кэшировать дерево, но тебе за память не страшно?)

Ну вот я и хочу кешировать куски дерева таким макаром. Дальше не страшно.

сотни аллокаций - это немного. как же иммутаблы? ))) они постоянно аллокируют)) вот миллионы микроаллокаций в секунды - это да)

Если это мусор то да (см там выше павлов говорит про оптимизацию на этот счет). А так там настоящие объекты, которые потом используются и живут какое-то время. Секунды, может быть даже минуты.

да и контролировать проще, можно сделать менеджера памяти простенького, который и по обьему ограничить и по времени

Возможно ты прав и викмэп тут не подходит и надо чистить по времени.

Но это как-то...

@fomkin ок, ну тогда самое просто и крутое что я вижу, это сделать это через мету и конкарент мапу

@fomkin или даже skiplismap

@fomkin и не забыть обернуть все value в softref

@fomkin и не забыть обернуть все value в softref

Зачем?

Зачем?

Чтоб если память кончится, jvm прибило это уг

Чтоб если память кончится, jvm прибило это уг

Ясно.

@fomkin вообще можно простой lru написать)))

@fomkin ConcurrentMap<K, V> cache = new ConcurrentLinkedHashMap.Builder<K, V>() .maximumWeightedCapacity(1000) .build(); в качестве ключа юзаешь функцию и параметры)

@fomkin https://code.google.com/archive/p/concurrentlinkedhashmap/

@fomkin кстати, можно попробовать сделать class с lazy val внутри, правда я хз как он себя проведёт пр оом

@fomkin кстати, можно попробовать сделать class с lazy val внутри, правда я хз как он себя проведёт пр оом

эм. а как он себя поведет иначе кроме как в соответствии со спецификацией? )) если доступ к полю будет запрошен, значит память выделиться и дальше убьется с очисткой экземпляра хоста, а до тех пор будет выделено только место под адрес для этого поля(ну и место для флажочка - создано, нет) при заведении экземпляра хоста)

это же как и многое другое - больше синтаксический сахар)

ктонибудь, кто читал статью De Goes-а про [Onion](http://degoes.net/articles/modern-fp-part-2) разобрался как там подразумевается имплементировать интерпретаторы которые должны выражатся в терминах другого интерпретатора ? вот это все: val bankingLogging : BankingF ~< Halt LoggingF val bankingProtocol : BankingF ~< ProtocolF val protocolSocket : ProtocolF ~< SocketF val loggingFile : LoggingF ~< FileF val execFile : FileF ~> IO val execSocket : SocketF ~> IO

Да я разобрался как их имплементировать и чейнить

Mikhail да, только спека частенько пиздит)

Только недавно дедлок зафиксили(вроде)

Единственное что я не совсем понял я отписал вопросм к статетье но пока не джон не отвтил

Да я разобрался как их имплементировать и чейнить

можно пример или описание идеи?

идея интерпретировтаь одну алгебру в другую

Mikhail хотя в спеке нет про дедлок не слова))) (

пример попробую щас накидать

Mikhail хотя в спеке нет про дедлок не слова))) (

а про thread safety есть?

идея интерпретировтаь одну алгебру в другую

вот не очень понятно на каком уровне это следует делать

а про thread safety есть?

Да там вообще спека ничего не гарантирует

тогда и претензий к ней нет)

На самом деле у скалы спека очень мелкая, можно сказать что скала нихера не гарантирует)

это да, не структурирована совсем(

На самую важную часть Одерски положил болт

пример попробую щас накидать

спасибо, будет интересно глянуть

спасибо, будет интересно глянуть

Пусть есть два языка Для работы с твитами sealed trait TweetOp[A] case class GetTweets(userId: String) extends TweetOp[List[Tweet]] ... И для работы с Http sealed trait HttpOp[A] object HttpOp { def get[A](url: String, decoder: Decoder[A]): Free[HttpOp, A] = Free.liftF(Get(url, decoder)) case class Get[A](url: String, decoder: Decoder[A]) extends HttpOp[A] } ... Пусть у тебя есть некая программа program: Free[TweetOp, List[Tweet]] и есть только интерпретатор httpToFuture: HttpOp ~> Future. А нужен TweetOp ~> Future. Значит не хватает TweetOp ~> Free[HttpOp, ?] или как у Джона alias TweetOp ~< HttpOp ну и делаем его val tweetToHttp = Lambda[TweetOp ~> Free[HttpOp, ?]] { case GetTweets(userId) => HttpOp.get(s"user/$userId/tweets", Decoder[List[Tweet]]) ... } val httpProgram: Free[HttpOp, List[Tweet]] = program.foldMap(tweetToHttp) val future = httpProgram.foldMap(httpToFuture) или val tweetToFuture: TweetOp ~> Future = λ[TweetOp ~> Future](x => tweetToHttp(x).foldMap(httpToFuture)) тогда val future = program.foldMap(tweetToFuture)

это вроде как transpiler называется

то есть мы программу на одном языке выражаем через другой

Если где то непонятно с радостью объясню

ну примерно понятно теперь, надо попробовать будет - я как то не догадался что через тайп лямду можно попробую поигратся тогда может конкретные вопросы появятся

окей

Если где то непонятно с радостью объясню

как быть, если есть 300 вариаций TweetOp ? делать 300 строчек case ?

можно дробить на под алгебры

@notxcain а вот тут он что имеет в виду? - какие utility functions есть для того чтобы это все миксовать? After implementing these interpreters, you can wire them together by using a bunch of seemingly unfamiliar utility functions that ship with Free implementations (more on this later).

ну я кроме как foldMap и compile ничего интересного не нашел

Посоны тяготеют к заумному коду. Паттерны умерли, да здравствуют паттерны!

Если у кого есть учетка JetBrains, прошу зайти и проголосовать за тикет https://youtrack.jetbrains.com/issue/SCL-10844

почему паттерны умерли

фриманатка это тоже паттерн

надо уже привинтить куда то! а то скоро в кровавом энтерпрайзе будет все во фримонадах!

что привинтить?

фриманатка это тоже паттерн

ну так о том и речь :)

фримонады куда нибудь!

ERROR: S client not available

а, в смысле в своём коде

ды да

а то как лох

Map[String, String] vs Map[String, Option[String]] если я не гарантирую, что для какого то ключа будет значение, что "идеоматичнее" ?

Первое

Так map же позволят option получить

.get она и есть String=>Option[String]

я тож к первому склоняюсь, но всегда же можно себе в ногу выстрелить через apply(key)

можно мапу создавать с дефолтным вэлью

как вариант

я тож к первому склоняюсь, но всегда же можно себе в ногу выстрелить через apply(key)

apply(key).get ? Разницы ж никакой

apply не опцию возвращает

апплай тут я так понимаю от PartialFunction

эффект монопенисуальный по сути)

можно мапу создавать с дефолтным вэлью

пожалуй, мой кейс, спасибо

@leammas http://scastie.org/22906

=) нормас отработало

у меня там можно не напрягаясь для всех ключей свои дефолтные значения извлечь)

apply не опцию возвращает

Я про второй вариант

только надо помнить что дефолтные значения после функций типа map превращаются в тыкву

Я про второй вариант

Так там же все равно будет NoSuchElementException, ну если только не делать дефолтным None

Я и говорю что человек сомневается в одинаковых вещах. Вы читали на что я ответил то? В 90% нет смысла в Map[Key, Option[Value]]

я бы сказал, что в 100%

не могу придумать подходящий кейc

ну если наличие ключа тоже несёт какую то информацию

может кто-то хочет явно задавать что надо брать default значение для каких-то ключех, но при этом оставить строгую проверку по ключам типа map = Map('key1' -> Some(Value), 'key2' -> None)

но типа если нет key3

можно ж сделать map.keys и прогнать

то должно ругаться типа нет key3

а не брать его дефолтное значение

но case так себе )