[01:45:56] <valexey> Ермаков продолжает боянчиками сыпать которые были опровергнуты неоднократно:
"В Haskell (по состоянию 2-3 года назад) память текла... Это при скольки годах уже существования?
В журнале ФП (который выходил тогда, кто помнит), товарищи писали про моделирование ЦП на Хаскелле и жаловались, что течёт, мол, память-то."
[08:23:26] <geniepro> valexey: это где он там клевещет?
[08:24:38] <geniepro> если он имеет в виду space leaks, которые не совсем то же самое, что memory leaks, то их можно легко устроить в любом языке, даже в любимом Ермаковым КП. Есть возможность динамического выделения памяти? значит есть возможность сделать space leaks
[08:27:29] <Kemet> geniepro: приведи рабочий пример на КП, а то это клеветы-же!
[08:28:04] <geniepro> выделить память можно? можно! ну всё -- выделяй память и не утидизируй её -- вот тебе и space leak
[08:28:41] <Kemet> эээ, как ее не итилизировать, если она автоматом тогос
[08:29:28] <geniepro> кто тебе даст её автоматом того, если ссылки на неё ещё активны? это ошибка работы GC тогда
[08:29:50] <Kemet> еслои ссылка активна, то тогда нет утечки
[08:31:08] <geniepro> ну как нет? ты её не используешь -- забыл про неё, а место она занимает -- вот тебе и space leak
[08:31:35] <Kemet> это не утечка
[08:31:42] <geniepro> а что это?
[08:32:12] <Kemet> утечка, это когда ссылок нет, а гк не может ее освободит ь в силу какихто багов
[08:32:18] <geniepro> место в памяти занимает? занимает. для работы не нужно? не нужно. значит утечка? утечка
[08:32:38] <geniepro> ты говоришь про memory leak, а я про space leak
[08:33:23] <geniepro> и то что Ермаков там клеветал -- это он тоже про space leak писал, думая что это memory leak
[08:33:31] <geniepro> а это разные вещи
[08:34:32] <geniepro> нет в хаскельных программах memory leaks, если не использовать unsafe-код, или код на си
но есть возможность устроить space leak, если не задумываться о форсировании вычислений когда надо
[08:38:04] <geniepro> и тут сколько бы языку не было -- это фундаментальная особенность ленивого языка, который вычисляет что-то только когда нужны результаты вычисления этого, а в остальное время хранит в памяти "путь вычисления", ну или алгоритм вычисления вместо самого значения
тут уже ничего не поделаешь, можно лишь как-то пытаться оптимизировать компилятор, что бы он уменьшил последствия этой проблемы
[08:38:22] <geniepro> ну или самому думать, когда лучше форсировать то или иное вычисление
[08:39:03] <geniepro> однако на хаскелле можно использовать и принудительное форсирование параметров функций и полей записей -- тогда эта проблема снизится
[08:39:32] <geniepro> но может измениться логика работы программы, так что нужно понимать, что делаешь
[08:43:20] <Kemet> https://wiki.haskell.org/Memory_leak
[08:49:54] <geniepro> Kemet: то что описано в этой статье -- это всё space leak, которые не тоже самое что memory leak
[08:50:43] <geniepro> ты же сам писал -- нет ссылок, а память занимается, тут же ссылки-то есть, просто бесполезно висят из-за того что не вычислены ещё
[08:51:17] <geniepro> Kemet> еслои ссылка активна, то тогда нет утечки
твои слова?
[08:52:13] <Kemet> если ссылка активна, то это не утечка памяти, да
[08:55:21] <Kemet> как мне помнится, в оберон системах файлы не закрываются даже если они не нужны. там даже нет такой возможности - закрыть файл, в однопользовательской системе это не проблема, но в многопользовательской может быть, а особенно когда она не на голом железе а на хосте. Поэтому в А2 таки добавили file.Close( ), чтобы можно было освободить хостовый файл, не знаю, есть ли такое в КП
[08:55:52] <geniepro> тут проблема в том, что приходится выбирать между экономией памяти с затратами процесссорного времени и экономией процессорного времени с затратами памяти
если потратить процессорное время на форсирование вычисления, то можно уменьшить занимаемое им пространство в памяти
если сэкономить процессорное время, то может понадобиться заплатить это памятью на хранение алгоритма вычисления
[08:56:39] <geniepro> однако в некоторых алгоритмах может быть что именно форсирование вычисления значения и приведёт к увеличению занимаемого им места в памяти
[08:57:02] <geniepro> тогда как ленивое его вычисление по необходимости может уменьшить затраты памяти
[08:57:09] <geniepro> короче от задачи зависит
[08:58:56] <geniepro> простейший пример -- вычисление бесконечного списка чисел фибоначи -- если его лениво печатать, то памяти он займёт мизер -- всего там нужно будет пару последних чисел в памяти держать плюс операцию их суммирования
если же форсировать его вычисления -- то память переполнится, список же бесконечный
[09:01:38] <geniepro> Kemet> как мне помнится, в оберон системах файлы не закрываются даже если они не нужны.
в расте открытый файл автоматом закрывается когда теряется его область видимости
[09:03:13] <Kemet> посмотрел последнюб сборку ББ от центра, там есть Close, надо ранбше глянуть
[12:36:57] <Kemet> valexey: не осилил я пока 64 битную фс для линупса в А2. мля там апи еще херовей чем в винде. я бы даже сказал что в винде норм с этим, ну за исключением нескольких моментов
[12:37:42] <Kemet> видимл поэтому они 64 битную ЮниксАос прибили
[16:01:44] <vlad2> geniepro: memory leak устоявщийся термин и он включает в себя случаи, когда что-то не может быть собрано GC потому, что с точки зрения GC оно не имеет право быть собранным. Поиск таких утечек не менее трудоемок, чем поиск сишных утечек (когда и ссылок нет и памяти не осталось) и эффект на системе тот же самый (out of memory в какой-то момент).
[16:04:10] <vlad2> Может с точки зрения какого-нибудь маркетинга и имеет смысл различать на виды, чтобы можно было порекламировать "в нашем ЯМ нет memory leaks", но на практике - одна фигня.
[16:04:26] <vlad2> ЯП
[16:05:09] <vlad2> Синоптики редиски не обманули! -17!
[16:32:17] <vlad2> "Фильм был призван заполнить сюжетную пустоту между 3-м и 4-м эпизодом "Звездных войн", рассказав о том, как в руки повстанцев попали планы "Звезды Смерти" и почему у нее была такая идиотская уязвимость."
Надо сходить :)
[17:36:58] <valexey> потому что на сях проектировали же!
[17:36:58] <valexey> проектировали бы ЗС на обероне - уязвимости не было бы!
[17:58:10] <NEW> на сях или хаскеле
[20:51:45] <vlad2> На обероне она была бы маленькой звездочкой :) 16*16*16 сантиметров :)
[20:56:58] <valexey> vlad2: вот! и без уязвимостей! круто же!
[20:57:03] <valexey> её фалькон просто не нашел бы!
[22:02:03] <Kemet> valexey: ты смог запустить бинарник от А2 на сервере?
[22:02:46] <valexey> который был oberon?
[22:02:49] <valexey> нет, не смог тогда\
[22:03:35] <Kemet> тогда не буду доделывать сортировку
[22:03:37] <valexey> т.е. это возможно, я уверен. но я криворук, увы.
[22:03:42] <valexey> я ещё попытаюсь.
[22:03:50] <valexey> на моем десктопчеге оно работает вполне.
[22:04:10] <Kemet> ну на моем тоже
[22:04:20] <valexey> была бы там ошибка информативней.. т.е. оно не нашло либу, или не смогло загрузить - это же две разные вещи
[22:06:45] <Kemet> скорее не нашло, как я понял из Убунты64 выпилили libc6:i386 и надо собирать из исходников
[22:06:58] <valexey> тогда xds не работал бы
[22:07:00] <valexey> а он работает
[22:07:03] <valexey> всё там есть
[22:07:51] <Kemet> ну, может онопод  другим именем
[22:10:39] <valexey> самое смешное, что оно пишет, что Unix.Dlopen: loading library libc.so.6 failed а затем не вылетает и не выходит, а зацикливается со 100процентной загрузкой СПУ
[22:45:55] <valexey> Kemet: смотри, удалил libc.so.6 в итоге оно вылетает с диагностикой:
[22:45:57] <valexey> # ./oberon
./oberon: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

[22:46:17] <valexey> а если восстановить симлинк, то оно пишет
# ./oberon
Unix.Dlopen: loading library libc.so.6 failed

[22:46:22] <valexey> и зависает нафиг
[23:19:10] <TRUE> а оно дружит с симлинками? Что если хардлинк?
[23:32:09] <valexey> дружит вроде
[23:32:19] <valexey> пробовал и симлинком и хардлинком и просто копией файла
[23:32:32] <valexey> т.е. оно файл находит, но фейлится
[23:32:39] <valexey> а диагностики нет нихрена :-(