Ответ на »сообщение 1654« (AVC)
___________________________

Ответ на »сообщение 1652« (pepper)
___________________________

Вопрос о раскрутке питона ставил не я.

Разве? А как же »сообщение 1631«?

И где там знак вопроса? ;) Во всяком случае ты виновен не меньше ;)

Ответ на »сообщение 1651« (AVC)
___________________________

Это просто компромисс, позволяющий сочетать надежность и эффективность.

А если у мена стеке мегабайтный массив?

Ответ на »сообщение 1652« (pepper)
___________________________

Вопрос о раскрутке питона ставил не я.

Разве? А как же »сообщение 1631«?

Ответ на »сообщение 1642« (Владимир Лось)
___________________________

Ответ на »сообщение 1641« (pepper)
___________________________
Хм... Интересно, что общего между динамически типизированным интерпретируемым языком и статически типизированным компилируемым языком? Неужели "модули"? :)
Траву свежую завезли? Что б никого не обижать - спишем на достаточно позднее время... :о)))))

Пока больше всех здесь веселишься ты ;) Кстати, ответ на свой вопрос я получил:
...showed up in Python's exception handling, modules, and the fact that methods explicitly contain ``self'' in their parameter list.

Ответ на »сообщение 1646« (Снегурочка)
___________________________

Вопрос о раскрутке Python с повестки дня тем временем товарищем pepper был тихо снят. Теперь будем разбираться в его технических деталях на форуме по Оберону? Ok.


Вопрос о раскрутке питона ставил не я. За цитаты спасибо, было интересно.

Ответ на »сообщение 1650« (Сергей Губанов)
___________________________

Ответ на »сообщение 1644« (Илья Ермаков)

В стеке же сборщик в ББ работает консервативно и по целым тоже "привяжет" объект.

Не понял. А если у меня на стеке полно всяких целых чисел, значения которых случайно совпадают с адресами каких-то объектов, то эти объекты никогда не будут удалены?

Будут. Когда в стеке не будет этих чисел. :)
В первоначальной ОС Оберон сборка мусора осуществлялась только между вызовами команд (т.е. при пустом стеке). Это, конечно, удобно, но...
А что делать, если потребность в сборке мусора возникла в процессе выполнения команды?
Проблема в том, что в отличие от статических указателей (якорей) адреса указателей в стеке в этот момент неизвестны (их можно восстановить, но это слишком накладно).
Вот GC и работает со стеком консервативно. Если некое 4-байтовое значение может быть указателем (совпадает с адресом участка, выделенного из кучи), то оно и рассматривается как указатель.
Это просто компромисс, позволяющий сочетать надежность и эффективность.

Ответ на »сообщение 1644« (Илья Ермаков)

В стеке же сборщик в ББ работает консервативно и по целым тоже "привяжет" объект.

Не понял. А если у меня на стеке полно всяких целых чисел, значения которых случайно совпадают с адресами каких-то объектов, то эти объекты никогда не будут удалены?

Ответ на »сообщение 1636« (Илья Ермаков)


PROCEDURE (w: WeakPointer) Target* (OUT ptr: ANYPTR), NEW;
VAR adr: INTEGER;
BEGIN
adr := w.adr; (* make anchor in stack, to prevent concurrent GC *)
ptr := S.VAL(ANYPTR, w.adr);
adr := 0
END Target;


Строка помещения якоря в стек необходима на тот случай, если произойдет прерывание на сборку мусора в середине инструкции ptr := S.VAL(ANYPTR, w.adr), и на объект больше не осталось ссылок. Тогда адрес объекта будет успешно извлечен в регистр, потом сборщик мусора, не найдя якорей на объект, обнулит указатель и удалит объект, но ведь адрес объекта уже был извлечен и будет возвращен... Поэтому до взятия адреса создаем якорь в стеке.

Я бы понял эту логику в том случае если бы якорем был указатель, но когда на стеке размещается не указатель, а просто какое-то целое число adr: INTEGER, то как целое число-то может послужить якорем? Мало ли какие целые числа на стеке лежат...

По моему, здесь в обязательном порядке нужно использовать функцию InterlockedExchange из Kernel32.dll, на базе которой реализовать свою процедуру InterlockedMove, её и использовать:

PROCEDURE (w: WeakPointer) Target* (OUT ptr: ANYPTR), NEW;
BEGIN InterlockedMove(ptr, w.adr)
END Target;

Ползучая гидра пробирается даже в девственно чистые ряды самого правильного языка всех времён и народов:о)))
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm

Ответ на »сообщение 1643« (Сергей Осколков)
___________________________

По-моему они если и конкуренты, то только в сфере веб-приложений.

Да, речь шла о конкуренции этих языков именно в web-программировании. И что из этого прямо вытекает - в общей популярности языков. По январскому рейтингу TIOBE языки PHP и Python на 5-м и 8-м местах соответственно.

См. http://www.tiobe.com/index.htm?tiobe_index