Ещё начиная с GHC 6.8 заметил, что через некоторое время после запуска GHCi (даже если ничего не делать) съедается память процесса в жутких кол-вах. Недавно обновился до 6.10.1, но проблема осталась и даже усугубилась (хотя это возможно апдейты висты усугубили): теперь после съедания процессом памяти ставится колом вся система.
Ни у кого не наблюдается подобного? Может есть способы лечения? А то жутко раздражает перезагружаться после случайно забытого запуска интерпретатора
A>Ещё начиная с GHC 6.8 заметил, что через некоторое время после запуска GHCi (даже если ничего не делать) съедается память процесса в жутких кол-вах. Недавно обновился до 6.10.1, но проблема осталась и даже усугубилась (хотя это возможно апдейты висты усугубили): теперь после съедания процессом памяти ставится колом вся система.
То есть, ты просто запускаешь ghci и совсем-совсем-совсем ничего не делаешь, а память отъедается?
Странно.
XP/MacOS X — такого нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, thesz, Вы писали:
T>То есть, ты просто запускаешь ghci и совсем-совсем-совсем ничего не делаешь, а память отъедается? T>Странно. T>XP/MacOS X — такого нет.
Хмм, не совсем так.
Воспроизвёл проблему по шагам.
1) Запускаю ghci — в процессах появляется два процесса ghci.exe и ghc.exe.
2) Запускаю несколько раз подряд компиляцию тестовой hs-программы:
main :: IO ()
main = do
print $ [x | x <- [1..]]
putStrLn "Hello, world!"
Для теста сделал запуск 20 раз, память приросла почти на 100Мб.
for /L %i in (1,1,20) do ghc -fforce-recomp -O --make "problem.hs" -o "problem.exe"
3) Во время выполнения предыдущей строчки наблюдаю использование процессора и некоторый рост занятой памяти у процесса ghc.exe принадлежащего ghci.
P.S. Проблема стабильно воспроизвелась и на ноутбуке с вистой.
Получается следующая ситуация: во время программирования чего-нибудь на хаскелле периодически запускаю интерпретатор, чтобы проверить какие-нибудь предположения, а затем возвращаюсь к программированию и соответственно компилятору. А интерпретатор тем временем медленно, но верно съедает доступную память до введения системы в полный ступор.
Здравствуйте, Andir, Вы писали: A>3) Во время выполнения предыдущей строчки наблюдаю использование процессора и некоторый рост занятой памяти у процесса ghc.exe принадлежащего ghci.
Наблюдаю то же самое.
Причём на шаге 2 достаточно просто вызвать компилятор с несуществующим файлом — память у первого экземпляра ghc всё равно будет увеличиватся...
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[4]: [Haskell] Проблемы с утечками памяти в GHCi
T>>То есть, ты просто запускаешь ghci и совсем-совсем-совсем ничего не делаешь, а память отъедается? T>>Странно. T>>XP/MacOS X — такого нет.
A>Хмм, не совсем так.
A>Воспроизвёл проблему по шагам. A>1) Запускаю ghci — в процессах появляется два процесса ghci.exe и ghc.exe. A>2) Запускаю несколько раз подряд компиляцию тестовой hs-программы:
Я компиляцию практически совсем не использую.
И тебе не рекомендую.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[4]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, thesz, Вы писали:
T>Долго.
Не дольше, чем C++ .
T>И тяжело быстро проверять результаты.
Понятно, что в процессе отладки удобно использовать repl (кстати, для проверки, сами понимаете, иногда приходится писать тесты — и repl особо не поможет).
Мне подумалось, что Вы хотите сказать, что уже готовое приложение не стоит компилировать, а всегда и везде запускать через runghc.
Re[6]: [Haskell] Проблемы с утечками памяти в GHCi
Для моих целей вполне достаточно у меня c# дольше компилируется, чем хаскель.
T>И тяжело быстро проверять результаты. T>http://thesz.livejournal.com/596553.html
Ну не знаю, не знаю. REPL это ещё и другая парадигма процесса создания программы по сути, к ней надо привыкать отдельно (если сразу с неё не начинать, конечно).
Пока мне привычнее взять текстовый редактор, повесить на кнопку компиляцию текущего файла и по накатанной.
А GHCi использую в качестве средства проверки некоторых утверждений, предположений. Впрочем, иногда, в особо трудных случаях (для меня неопытного в хаскеле) пользуюсь полезными штуками :t, :k и т.п. загружая текущий исходник.
T>>И тяжело быстро проверять результаты.
M>А как из ghci результаты работы в .hs засунуть ? M>Ну поигрался в REPL. Функции написал,проверил. M>Как сохранить то ?
Функции надо писать в редакторе. Основные.
Вспомогательные — в строке REPL.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, Mirrorer, Вы писали:
M>А как из ghci результаты работы в .hs засунуть ? M>Ну поигрался в REPL. Функции написал,проверил. M>Как сохранить то ?
С помощью IDE.
Например в Emacs окно REPL это обычное окно редактора, из которого можно копировать, вставлять и пр.
... << RSDN@Home 1.2.0 alpha 4 rev. 1136>>
Best regards, Буравчик
Re[8]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, thesz, Вы писали:
T>Функции надо писать в редакторе. Основные.
T>Вспомогательные — в строке REPL.
Ну в общем идея ясно. Просто по поводу workflow разработки хотелось уточнить. За счет чего с REPL разработка быстрее.
Вот допустим возьмем ИДЕ. пущай для C#. Как там выглядит процесс разработки. В редакторе набрал код, написал на него юнит тесты скомпилил, запустил тесты. Если где-то что-то свалилось — опять в редактор и по новой.
Минус — может быть долгая компиляция.
Плюс — повторяемость тестов.
Для этого случая юнит-тесты можно считать отдаленным аналогом REPL.
С REPL для хаскела. в редакторе кода набрали код. переключитилсь в окно интерпретатора. сделали load файла.
Поигрались с функцией допустим
let f x = foldl (*) 1 [0 .. x]
в окне ghci поняли что на самом деле надо писать
let f x = foldl (*) 1 [1 .. x]
выделили, скопировали в буфер.
Убили старуе версию кода в редакторе, вставлии новую.
Минус — отсутствует повторяемость тестов.
слишком много движений для копирования функции из окошка REPL. А ежели функция строчек на 10 ? Плюс лично мне неудобно работать с табуляцией в окне GHCI. Умные табы в емаксе в этом плане хороши.
Я думал что есть какая-то хитрая фишка, позволяющая сохранять измененную функцию из окна интерпретатора сразу в файл, с заменой старой версии функции. Вот это было бы реально круто.
По-моему работа в нормальном IDE, с юнит тестами, интелисенсом и проч. (VS2008, IDEA, Eclipse) позволяет быстрее вести разработку чем хороший редактор (Vim, Emacs) с интерпретатором.
Re[9]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, Mirrorer, Вы писали:
M>Вот допустим возьмем ИДЕ. пущай для C#. Как там выглядит процесс разработки. В редакторе набрал код, написал на него юнит тесты скомпилил, запустил тесты. Если где-то что-то свалилось — опять в редактор и по новой. M>Минус — может быть долгая компиляция. M>Плюс — повторяемость тестов. M>Для этого случая юнит-тесты можно считать отдаленным аналогом REPL.
REPL и тесты не заменяют друг друга. REPL не для тестов, они для быстрой-быстрой проверки или получения информации, необходимой для написания кода. 10 строковую функцию в REPL я не писал ни разу
M>Я думал что есть какая-то хитрая фишка, позволяющая сохранять измененную функцию из окна интерпретатора сразу в файл, с заменой старой версии функции. Вот это было бы реально круто.
Не знаю, я не чувствую необходимости. REPL не для дублирования кода. Он для проверки мыслей, ну и частично заменяет интелесенс.
M>По-моему работа в нормальном IDE, с юнит тестами, интелисенсом и проч. (VS2008, IDEA, Eclipse) позволяет быстрее вести разработку чем хороший редактор (Vim, Emacs) с интерпретатором.
А я всё реже запускаю Эклипс
Re[10]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, lomeo, Вы писали:
L>REPL и тесты не заменяют друг друга. REPL не для тестов, они для быстрой-быстрой проверки или получения информации, необходимой для написания кода. 10 строковую функцию в REPL я не писал ни разу
Наврал. В Лисповом REPLе писал, конечно же. Я говорил про GHCi — REPL для языка со статической типизацией.
Re[10]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, lomeo, Вы писали:
L>REPL и тесты не заменяют друг друга. REPL не для тестов, они для быстрой-быстрой проверки или получения информации, необходимой для написания кода.
Тесты тоже для проверки
А вот возможность проверки в рантайме это конечно плюс. То есть подключиться к работающей системе, функциями проверить ее состояние и что-то подправить при необходимости. Впоминается история из Practical common lisp, как товарищи дебажили по живому лисп-систему работающую на спутнике за много мульенов, летающем в космосе.
Но такие возможности больше нужны на этапе прототипирования или же в глубоком багфиксинге.
L> REPL не для дублирования кода. Он для проверки мыслей, ну и частично заменяет интелесенс.
По поводу интелисенса можно развернуть ?
Re[11]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, Mirrorer, Вы писали:
L>> REPL не для дублирования кода. Он для проверки мыслей, ну и частично заменяет интелесенс. M>По поводу интелисенса можно развернуть ?
Ну, не автокомплишн, разумеется. Я имел в виду получение информации по идентификаторам — типы, определения, зависимости.
Re[12]: [Haskell] Проблемы с утечками памяти в GHCi
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, Mirrorer, Вы писали:
L>>> REPL не для дублирования кода. Он для проверки мыслей, ну и частично заменяет интелесенс. M>>По поводу интелисенса можно развернуть ?
L>Ну, не автокомплишн, разумеется. Я имел в виду получение информации по идентификаторам — типы, определения, зависимости.
Если мы всё ещё в GHCi, то что там есть зависимости?
у меня c# дольше компилируется, чем хаскель.
