мои ходы получились равномерно размазанными, а у бота более точечные

у него было 3 хода в одном квадрате, против моего одного хода там

впечатление, что распределение в каком квадрате тебе ходить не верное

В смысле? Оно не случайное.

Как выстроишь стратегию, так и будет.

Прикольная идея с выбором квадрата для следующего хода соперника

https://twitter.com/hintjens/status/783254242052206592

Блин слежу уже второй день

эмоции странные

это круто и грустно одновременно

у нас так не получится

карательная медицина просто так не отпустит

но вообще как то грустно

грустно да, но читаешь все слова которые ему пишут и то как он сам это воспринимает и от этого проще.

Ну он ваще смирился я так понимаю

видимо боль уже была невыносимой

а что это за замечательный чел? и о чем грусть?

автор 0mq

и разных статей и книжек про построение распределенных приложений

/scala

/scala

Сегодня это тренд ?

-

/scala

выпнули бота уже

/scala

/scala

/scala

/scala

А что за бот, хоть был. Я все пропустил

А что за бот, хоть был. Я все пропустил

@rextester

There is no Telegram account

@rextester_bot, сорри

О, отклонено

*прикольно

ребят кто использвол паркет на спарке? есть разница в сокрости / еще чем-то использования встроеного api или используя io форматы паркета?

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

там не столь важен спарк, сколько кейс

етиэльщики на работе пробовали разные форматы и менялось от случая к случаю

подробностей не дам, они ничего не сохранили

ну грубо говоря это большая массивная рдда пар (sfc ключ, блоб)

а с чем разница интересует?

с ORC типа?

или с голым hdfs?

если правильно помню, паркет по устройству близок к column family

это колоночный формат, да

с соответствующими следствиями

да не всего лишь ParquetInputFormat / ParquetOutputFormat vs DataFrame.write. … .parquet(path) исходя из того что у меня уже есть RDD и мне нужна рдда

хз гипотетически разницы быть не должно, потому что работа должна быть сделана примерно одна и та же, только в разные моменты времени

а зачем тебе паркет, если тебе с рдд работать?

хочу понять имеет ли смысл скуль запросы писать или нет o:

DataFrame.write сильно удобнее - правильно смаппить схему для ParquetOutputFormat - тот еще геморрой. Кроме того, он пишет всякую метадату, которая помогает при чтении. Т.е., при фулскане разницы не будет, а вот если надо селектить и обрабатывать, типа, 1% данных - разница достаточно серьезная. Перегонять данные RDD <-> DataFrame неудобно, гораздо приятнее RDD <-> Dataset (в Spark 2.0)

а можно подробнее об этом? но похоже паркетное апи поверх датафреймов ._. да и сами датафреймы теперь Dataset[Row]

Можно и поподробнее, только что именно? :)

да в общем-то фигня вопрос перегнать RDD в Dataset[Row]. У тебя там 2 филда?

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

https://www.youtube.com/watch?v=q4y0KOeXViI

чет у гугла все бедненько

ERROR: S client not available

особенно, если не два филда, а упоротая схема с вложенными полями

да я прост по сигнатуре смотрю что датафремй алиас датасета)

да понял уже; когда запросы делаю ._. но используя трифт тоже вроде не сложно

коллеги, а есть среди нас chuwy24 с реддита?

кто знает, volatile переменная будет записана в память или может быть также записана в l3 cache ?

в кеш нельзя записать

как проц решит, имею ввиду

ну если подумать, то она не должна туда попадать

в кеш? Как думаешь?

или нет, как я понимаю тут надо асму куритьи в зависимсоти от инструкций проца)

https://shipilev.net/blog/2014/jmm-pragmatics/ https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/ я думаю тут будет ответ на вопрос выше)

tldr, но поиск по ключевым словам там ничего не дал

но спасибо)

а в чем польза от полученного ответа на этот вопрос?

пользы никакой

https://habrahabr.ru/post/157163/

я имею ввиду джавовский/скаловский volatile

ну если ты думаешь на уровне "как получается так что в кеш не попадает" - то выходит что это решается за счет транслирование байт кода, в инструкции вот такого типа

по моему волотайл это про видимость значений, как это будет реализованно в кэшах уже детали

по моему волотайл это про видимость значений, как это будет реализованно в кэшах уже детали

тут согласен, просто стало интересно вдруг

@fomkin Алексей, в пушке неизбежно требуется переименование полей json, когда работаешь с sealed trait? example - https://gist.github.com/optician/bc84be89557e9a0e93baeddba0b5e7e6

@fomkin Алексей, в пушке неизбежно требуется переименование полей json, когда работаешь с sealed trait? example - https://gist.github.com/optician/bc84be89557e9a0e93baeddba0b5e7e6

Не очень понял вопрос. Во втором случае будет что-то типа { "subModel": { "d1": {"field1": 10, "field2": [2,3,4,5,6,6,7]} }, "i": 5, "str": "some string value" }

У меня хитрый вопрос: в фп языках есть Option почему нет Required?

все что не Option?

всё что не опшн может быть null

в фп языках нет null

ага и в scala тоже