Size: a a a

2021 March 04

JS

Jerzy Syrowiecki in Haskell
Denis Gabidullin
Надо сделать как в анекдоте про нового председателя)
а как вы думаете, как я стал здесь админом?
источник

DG

Denis Gabidullin in Haskell
Jerzy Syrowiecki
а как вы думаете, как я стал здесь админом?
😂👍
источник

UT

Unknown T. in Haskell
Добрый вечер, не подскажите группу по lisp?
источник
2021 March 05

к

кана in Haskell
[BRM]White Rabbit
Не, ты сейчас про виртуальные потоки, они не дают буста производительности, только возможность многозадачности программы
как это не дают, если дают. Пока один поток ждет что-нибудь от бд, другой чет странсформирует
источник

[

[BRM]White Rabbit in Haskell
Ну, они позволяют не блокировать поток выполнения приложения при использовании длительных по времени функций, окей.
Я имел ввиду то, что какой-нибудь алг полезно параллелить на физические ядра, а на виртуальные - юзлесс.
Я помню даже говорил где-то пару месяцев назад, что в среднем для ио надо использовать зелёные потоки, а для вычислений - ядра процессора.
источник

A

Aleksandr Khristenko in Haskell
кана
как это не дают, если дают. Пока один поток ждет что-нибудь от бд, другой чет странсформирует
Окей, но с потоками оси такая-же фигня. Пока один поток будет ждать что-нибудь от бд другой чет странсформирует.
источник

A

Aleksandr Khristenko in Haskell
[BRM]White Rabbit
Ну, они позволяют не блокировать поток выполнения приложения при использовании длительных по времени функций, окей.
Я имел ввиду то, что какой-нибудь алг полезно параллелить на физические ядра, а на виртуальные - юзлесс.
Я помню даже говорил где-то пару месяцев назад, что в среднем для ио надо использовать зелёные потоки, а для вычислений - ядра процессора.
А вообще, ведь единственная причина использовать зеленые потоки для ИО в том, что потоки оси тяжеловесны.
источник

[

[BRM]White Rabbit in Haskell
ещё в том, что зелёных потоков можно насоздавать чуть ли не сколько хочешь. Там вроде бы есть ограничения, но для базированных задач они практически недостижимы
источник

A

Aleksandr Khristenko in Haskell
[BRM]White Rabbit
ещё в том, что зелёных потоков можно насоздавать чуть ли не сколько хочешь. Там вроде бы есть ограничения, но для базированных задач они практически недостижимы
Ну я и говорю, если бы потоки оси были легковесны и их можно было создавать сколько хочешь зеленые потоки были бы и не нужны.
источник

MP

Misha Puzanov in Haskell
Aleksandr Khristenko
А вообще, ведь единственная причина использовать зеленые потоки для ИО в том, что потоки оси тяжеловесны.
ну зеленых можно насоздавать, скажем, полмиллиона, и оно будет как-то шевелиться. И можно, например, открыть таким образом полмиллиона соединений (со всеми оговорками про системные лимиты).
источник

MP

Misha Puzanov in Haskell
с системными так просто вряд ли получится
источник

[

[BRM]White Rabbit in Haskell
Misha Puzanov
ну зеленых можно насоздавать, скажем, полмиллиона, и оно будет как-то шевелиться. И можно, например, открыть таким образом полмиллиона соединений (со всеми оговорками про системные лимиты).
ага. А системных потоков всего 8/16/32 получится
Не ну вообще идеально виртуальные потоки по ядрам распределить, но тут уж как получится
источник

ПК

Паша Калугин... in Haskell
как понять, где возникает бесконечный цикл при парсинге жсона?
источник

ПК

Паша Калугин... in Haskell
использую aeson
источник

к

кана in Haskell
а парсер кастомный или сгенерированный?
источник

ПК

Паша Калугин... in Haskell
сгенерированный
источник

к

кана in Haskell
а покажи тип
источник

к

кана in Haskell
звучит как какой-то рекурсивный тип с одним конструктором, из-за чего нет тегов, и парсер вызывает сам себя, ничего не потребив
источник

K

Kir in Haskell
кана
звучит как какой-то рекурсивный тип с одним конструктором, из-за чего нет тегов, и парсер вызывает сам себя, ничего не потребив
Типа data List a = List (a, List a)?
источник

к

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