PyPy 1.7

он не гарантирует очистку памяти

В смысле?

как связан _язык_ ява и графика?

Ты укуреный?

> Это не многозадачность.

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

>> он не гарантирует очистку памяти

В смысле?

Они где-то писали, что они стараются очистить все объекты, но не обещают, что смогут очистить все.

>Питон тормоз, и годится для таких задач, где производительность не играет роли, это же очевидно.

Еще раз раскажите это FriendFeed И кстати ребята Java знают точно лучше вас!

> Если полноценной поддержки потоков не будет, его можно хоронить. Процессы, даже с использованием shmem не проканают.

Я могу ошибаться, но у Эрланка вообще понятия потоков нет. Все работает само.

А графика? Да вы что? У C есть биндинги к GTK? Нет? Ааааааа GTK на нем написан? Мне вообще такой толстый тролль давно не попадался. Теперь у нас вызовы C библиотек стали тормозить. Стек мешает?

Чорт, точно. Если есть метод __del__ то оно дуба даёт и требует ручного удаления ссылок. Ну, это не сильно большая проблема, решается в пару строк :)

у нас память не чистится. объекты со стека не удаляются. течет

> Я могу ошибаться, но у Эрланка вообще понятия потоков нет. Все работает само.

У эрланга есть внутренние процессы. Причем это именно процессы, у них свое «адресное пространство», они ни содержат разделяемых объектов. Умные люди в ерикссон понимали еще 20 лет назад, что разделяемые объекты - лишний гемор, необходимость синхронизации и трудноуловимые ошибки.

А процессы там внутренние, потому что операционки с таким числом процессов не справляются. Как то для интереса запускал 2 миллиона процессов. Съело 2 гига памяти, но работало. Запустите как 2 миллиона потоков в жабе или питоне.

gc.collect() вызывали?

Если да то вот это поможет:

def liquidator():
    gc.collect()
    print(gc.garbage)
    for sucker in gc.garbage:
        sucker.__dict__.clear()
    del gc.garbage[:]

Правда, это весь код поломает... Интересно, а как в яве решена эта проблема?

Да, вызывали.

Интересный код. А что он вообще делает? У нас еще куча weak линков

>У эрланга есть внутренние процессы. Причем это именно процессы, у них свое «адресное пространство», они ни содержат разделяемых объектов. Умные люди в ерикссон понимали еще 20 лет назад, что разделяемые объекты - лишний гемор, необходимость синхронизации и трудноуловимые ошибки.

Дай я тебя в лоб поцелую. Вот примерно так я и считаю.

>Правда, это весь код поломает... Интересно, а как в яве решена эта проблема?

Никак. У них сабстринг не возвращает новый стринг. Он хранит ссылку на исходник и в итоге если ты с гиговой строки выбрал три смвола и всю дорогу их хранишь - гигова строка сидит в памяти ибо ссылка на нее жива.

Короче, косяк в том что если есть циклические ссылки у объектов с __del__ то непонятно в каком порядке их вызывать(я так понимаю это фундаментальное ограничение reference count).

Этот код тупо убивает инстанс(убирает рефы на все локальные переменные) со всеми его циклическими ссылками.

Собстно, в этом вся и проблема, после этого __del__ вызывать бессмысленно т.к. и так уже всё подтёрто самым поганым образом.

Как это в яве обошли я с ходу не понял. Там какие-то финалайзеры вызываются. Но, походу, из-за явовского tracing-коллектора компилер лучше понимает порядок вызова деструкторов, вот и всё.

> Короче, косяк в том что если есть циклические ссылки

По идее у них есть какая-то эвристика. Вот из-за нее может и не удаляться даже нормальный объект.

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

Вспомнил, я в простом проекте на 200 строк посадил очень хитрую петлю которую я искал оочень долго. Да, ты прав, gc в питоне не очень :(

Циклические ссылки в большинстве случаев указывают на кривость архитектуры.

И снова спасибо erlang'у, что не дает мне отстрелить себе ногу)

По идее у них есть какая-то эвристика

Нету :). На сколько помню, оно просто строит граф и смотрит не образовалось ли изолированных островков. Могу ошибаться, года два назад доки читал. Где-то в тутториале было что надо делать. С ходу нахожу только вот это: http://docs.python.org/py3k/c-api/gcsupport.html

Циклические ссылки в большинстве случаев указывают на кривость архитектуры.

это так кажется. На самом деле посадить нехрен делать.

> это так кажется. На самом деле посадить нехрен делать.

Абсолютно не понял смысла фразы

>Нету :). На сколько помню, оно просто строит граф и смотрит не образовалось ли изолированных островков.

Есть! Я еще в 1.5 читал как они борются. Там не Эвристика, а типа подсчет обхода элемента графа. как только пошли по второму кругу значит цикл. Удаляет, проверено

Есть!

ну я об этом же написал :).

Абсолютно не понял смысла фразы

Смысл фразы в том что даже при аккуратном подходе к программированию циклические ссылки всё равно появляются.

Потом кто сказал что так делать нельзя? Если есть цикл это не значит автоматом что программа жутко запутанная.

>ну я об этом же написал :).

Ну это не эвристика. Эвристика это на основе нечеткой логики или нейронных сетей. Или на основе статистики. Короче Эвристику сам пейсатель ХЗ предскажет в общем случае. Ненавижу. Но бывает полезно.

Потоки в питоне есть но они не используют преимущества многоядерных процессоров, спасибо GIL.
Начинал нормально изучать программирование как раз с Perl (не считая шела) , позже параллельно начал изучать Python. Когда дошел до нужного уровня все проекты делал на Python так как это было легче и понятнее, также из-за того что уже как года 3-4 падает спрос на Perl разработчиков. Да и изначально Perl был предназначен для обработки текста . В общем по своему опыту не советую на Perl ничего делать, 6ю версию уже 11 лет пишут :)

У Эрланга внутренее устройство и сложнее и проще. Там с циклическими ссылками проще. Там не так с объектами. Функции, данные. Очень лаконично и бесит ООП маниаков. Но у него свои проблемы.

> Смысл фразы в том что даже при аккуратном подходе к программированию циклические ссылки всё равно появляются.

Они появляются оттого, что люди не знают, как сделать по-другому.

Потом кто сказал что так делать нельзя? Если есть цикл это не значит автоматом что программа жутко запутанная.

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

Я начинал с Pascal потом был Perl (три года или 4) потом долго выбирал Руби или Пайтон. Еще TCL юзал. GIL есть, но я еще ни разу не попадал в ситуацию чтоб ох ох. Выделл в процессы и т.п. Удобный лаконичный язык. Могу еще про эрланг позавидовать и про окамл. А так всё есть. Идиоты отсеиваются, обидно что народ не много, одному писать чтолибо тяжко.

Они появляются оттого, что люди не знают, как сделать по-другому.

они появляются от того что так удобно.

Это возможно, когда объекты находятся на одном уровне абстракции

мой случай.

Очень лаконично и бесит ООП маниаков

Упс, тогда мне не подходит :). Вообще, честно скажу, года четыре назад пробовал, мне показалось очень гиковской вещью и неудобной на моих задачах.

Ну это не эвристика

я прямо так и сказал, написал что нету там эвристики :)

> В общем, для питона, похоже, самый лучший способ избежать проблем это не создавать циклические ссылки.

Более очевидный способ - не писать свой __del__.

Более очевидный способ - не писать свой __del__.

Ну __del__ не просто же так придумали.

> они появляются от того что так удобно.

Копипаст тоже удобнее и проще выделения общего функционала.

мой случай.

А можно пример?

> Более очевидный способ - не писать свой __del__.

Ну __del__ не просто же так придумали.

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

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

Что отстрелить позвольте? __del__ написали чтоб тот кто написал объект подумал и наиболее эффективным способом освободил все, что он захватил. В 80% он не нужен, но в 30% он помогает. Гап в 10%

Что отстрелить позвольте?

не позволю :)

__del__ написали чтоб тот кто написал объект подумал и наиболее эффективным способом освободил все, что он захватил.

ОМГ, эффективные деструкторы ценой утечек памяти? nowai, пусть лучше будут неэффективными

>до 20 раз быстрее

когда я вижу такое, я точно уверен, что впереди прирост еще в двести раз.

>ОМГ, эффективные деструкторы ценой утечек памяти? nowai, пусть лучше будут неэффективными

Тут человеческий фактор. Дай дураку стеклянный х....

>когда я вижу такое, я точно уверен, что впереди прирост еще в двести раз.

И это правда.

> Он там не сломается? Хотя не дожен, а идея мне опнравилась. С какой стати сломаться должен? multiprocessing-Ом это еще и в красивую обертку за вернуть можно. Одна только проблема, если там результат вычислений еще на 1Тб, то обратно собрать его будет проблемно.

ОМГ, эффективные деструкторы ценой утечек памяти?

Не подмешивай проблемы конкретной реализации. Тут не от деструкторов надо избавляться, а от проблемы.

А можно пример?

Да легко. В дочернем классе делал self.func_old = self.func_new или типа того чтобы подменить коллбэк (долбаный aio, тогда ещё не придумали gevent). Этого хватило. Да, говнокод(давно дело было), тока попробуй определи где сдесь цикл создаётся.

>ОМГ, эффективные деструкторы ценой утечек памяти? nowai, пусть лучше будут неэффективными

Тут человеческий фактор. Дай дураку стеклянный х....

...а второй потеряет :)

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

но обвинять GC в том что он не исполняет чьи то эротические фантазии и на этом мощном базисе делать заключения о годности/негодности - это через чур

да, имеет свои ограничения, да довольно простенькие алгоритмы, но плохой?..

Тут не от деструкторов надо избавляться, а от проблемы.

а в чём проблема - в руках, или в голове?

eval()?

По-твоему, деструкторы не нужны?

> Стать стандартным Питоном во всех дистрах :)

А срок на который намечен cpython-капец?

Не так давно пробовал fuzzy-search (нечеткий поиск, разница строк: levenstein) сравнить. Использовались списки (точнее, насколько понимаю, аdjustabje arrays). На порядок медленней.

> Python просто создан для веба, идеальный язык

Пруф?