Владимир (Все сообщения пользователя)

s_mike@rambler.ru, Динамическая типизация тут ПРИ ЧЁМ! Чуть не в половине веток этого форума обсуждаются проблемы, так или иначе связанные с тем, что программист лишён возможности определять тип переменных, который зависит лишь от того, какая именно моча ударит в голову исполнительному механизму в данный момент. А "чтецам документации" я уж цитировал давнее: "Читайте сами, раз уж ничего оттуда внятно процитировать не можете". И ответьте на вопросы ветки, господин "понимающий": С КАКОГО БОДУНА "все работает, а опционы к вечеру статус = 0, хотя все торгуется"? С КАКОГО БОДУНА техподдержка рекомендует использовать param_image, а не param_value в получении статуса? С КАКОГО БОДУНА конструкция
iT=tonumber(GetCell(T,p1,0).image);
работает, а
iT=tonumber(GetCell(T,p1,0).value);
НЕ работает? С КАКОГО БОДУНА OnTrade и OnOrder дают по 2-3-4 прерывания на одно событие? В какой такой "документации" это написано, господа "рядовые программисты"? Вон, там написано, что в языке и goto есть, а на проверку там кастрированное убожество, которое абсолютно нихрена не умеет. Молчите? То-то же...  

Этот маразм с этой долбаной "динамической типизацией" вообще вряд ли кто может объяснить. Я вот тоже вынужден использовать код вида:
iT=tonumber(GetCell(T,p1,0).image);
поскольку "нормальная" конструкция работать напрочь отказывается. А param_image вроде как всегда строка. И вообще, за динамическую типизацию руки-ноги бы повыдёргивал всем козлам, которые этот кретинизм придумали, ибо они АБСОЛЮТНО нихрена не понимают в программировании.

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

Я формирую таблицу в мейне, заполняю её строками (удаляю ненужные или добавляю недостающие) тоже в мейне (раз в 15 секунд), заполняю ячейки данными тоже в мейне (раз в секунду) - тогда и получаю необходимые данные (через GetParamEx) для нескольких сотен инструментов разных классов. Времени это не жрёт, от слова "совсем". И никаких коллбэков, от того же самого слова. Исключение - OnStop и OnTrade. Чего и  другим советую.    

Столь же понятно, что никто этот продукт не купит и за 50 деревянных.  

Сделать такой скрипт можно за 5 секунд. Достаточно поставить в цикле мейна sleep(300000), а в обработчике поставить messagе("МОЖНО!")    

Евгений, А это уж как кому заблагорассудится. Лично я плюю на них на всех с высокой колокольни.    

Виталий, Конечно, "на Lua были и есть траблы". Но они более-менее стабильные: отладил - и забыл на долгие годы.

ЧАВО???!!! Какие "100500 строк кода"?! Вот фрагмент основной таблицы моего скрипта (сегодняшний слепок) - раскрашен, как попугай! Блин, как тут картинку-то вставить? Ага, кажись, вот так...

Не знаю, не знаю. Я вот как раз и рассчитываю, что этот мой скрипт и будет "5 лет без сбоев работать". А у Билла и было-то три операционки: DOS 3.3, Win-95, да WinNT - какой уж тут, в задницу, "прогресс"...

Виталий, Господи, я прекрасно понимаю, что интерпретируемый язык на 1-2 порядка медленнее. Но кому нужен ТАКОЙ код? Нормальные алгоритмы торговли времени почти не требуют.

Насчёт "есть логика, которую банально удобнее и проще реализовывать на иных языках" - вообще-то, согласен: меня в своё время дико раздражало отсутствие типа integer и булевых операций. Но вот зачем "lua отдает данные во внешку" - это выше моего понимания!

Насколько я вижу по этому форуму, проблемы с переходом на новую версию возникают как раз не у тех, кто пишет на lua (кстати, есть тут такие, кроме меня?), а как раз у "альтернативщиков". А чего "чинить логику"? Во всех языках чуть не самая стабильная конструкция как раз if-then-else. Я и писал на lua, и других агитировал это делать как раз под этим самым лозунгом: "Меньше шансов, что в очередное "полезное" обновление что-то отвалится".

Да, я именно "логами и мессагами" и отлаживался. А "удобным отладчиком" не пользуюсь вот уже лет 30 - с тех пор, как нарвался, что в сложных случаях глючит как раз пошаговый отладчик.

Ну да, в Lua у нас таблицы, причём безобразно сделанные и глючащие. А что ещё нужно, кроме "примитивных ячеек и кликов по ним"? Ну, горячих клавиш пара-тройка. У меня одна таблица информационная (динамически обновляемая, имеющая три режима выдачи), а вторая - контекстное меню для каждой строки первой таблицы! Накидать его можно... ну, не за секунды, а за пару часов. Накидал и забыл! Много дней у меня уж работает этот диалог, и он меня ПОЛНОСТЬЮ устраивает! Всё, у меня диалог ГОТОВ! Написан и забыт. Остались небольшие проблемы с этими долбаными прерываниями, которые тут приходят целой колодой, да ещё вразнобой. Ну и шлифовка своих алгоритмов - всю эту неделю скрипт торгует в автоматическом режиме, а я за ним присматриваю и пытаюсь понять: лучше меня он торгует или хуже. Результат явно не в мою пользу, так что даже и не знаю, что там ещё улучшать.  

Виталий, Вот режь меня, жги меня - НЕ ПОНИМАЮ, зачем здесь более быстрый язык! У меня и весь диалог, и вся индикация, и весь обмен с сервером написан на чистом Lua, и скрипт большую часть времени просто спит! Держит при этом несколько десятков тикеров (моделировал пару тысяч - разницы по скорости вообще не заметил). Свечи считаю сам (по десятку разных временных периодов), стоп-лоссы отслеживаю сам - НУ ЧТО тут может отжирать время, НУ ЧТО? О какой-никакой стабильности можно говорить как раз относительно Lua - дерьмо, конечно, но стабильное. А уж если тут определяют номера версий софта, настраиваются на них - какая тут может быть стабильность?

Александр, Лапуль, я уже говорил, что с раннего детства терпеть не могу распальцованных дураков. Гнутых пальцев я тут уже видел выше крыши, а программистов - полтора человека, и уж Вы никоим образом к ним не относитесь. Так что НЕ ВАМ что-то тут вякать про "пора менять работу".   И говорил уже тыщу раз: задачи организации торговли настолько элементарны, что решаются ЛЮБЫМ способом. В частности, на чистом Lua, без всего этого маразма с обилием языков, библиотек, версий и прочей лабуды.

Старатель, Тип "string" всегда и везде, иначе наверняка ещё пару лет будут проблемы.    

Александр, Я всегда спокоен, лапуль. И глюки все давно исправил. Вернее, один остался- не знаю, как именно исправлять - может, и не буду, заглушка на этот глюк (не мой, Квика - я о нём писал) и сейчас работает нормально.  

Александр,  Тут всем пора менять работу - программисты вымерли. Логика на C++, интерфейс на C#, форум по Lua...

У меня опыт работы 30+ лет, и я не могу "связать 3 интерфейса, чтобы запустить сборку". Более того, считаю это клиническим маразмом, так что сделал логику на Lua, интерфейс на Lua и всё остальное тоже на Lua.    

Виталий, Не вижу ничего странного. Дело денежное и, следовательно, должно быть полностью подконтрольным. Тут просто не может не быть монополии! Вы полагаете, что какой-нибудь Сбербанк позволит использовать не аттестованное им программное обеспечение? Ну, конечно, должна быть создана видимость некоторой конкуренции. А конкуренции быть не может по определению - слишком проста математика для обеспечения сделок на бирже. Проста, понятна и логична. А потому весь этот туман от лукавого. Это не технические проблемы - это только политические.

Nikolay, Да я понял, понял - "зачем просто, когда можно сложно"?

НАФИГА юзеру "много тонкостей и нюансов"? Прошла сделка - пришло ОДНО прерывание, и дело с концом! Прошло изменение завки - тоже пришло ОДНО прерывание. А эти "тонкости" обычно называют "глюками".

Ну, хорошо: "все это обсуждалось на этом форуме уже много много лет, предложены разные варианты решений". Эти предложения РЕАЛИЗОВАНЫ, наконец, или "как всегда"?

Да мне плевать на таблицу trades - я туда вообще не лезу никогда! Пусть там "номер транзакции появляется не всегда сразу" - мне какое дело? вот когда он "потом меняется на корректный" - тогда и дайте мне НОРМАЛЬНЫЙ OnTrade! Неужели за "много лет" такого "варианта решения" так и не было предложено? Ну, ловите - предлагаю...    

Виталий, Аналогов этому терминалу нет и не будет. Ибо задачи разработчиков диаметрально противоположны задачам пользователей: им не нужна стабильно работающая версия, им нужен непрерывный апдейт для имитации бурной деятельности. Алгоритмически задача торговли тупа до неприличия: есть какие-то курсы, которые либо растут, либо падают, либо стоят на месте, И ВСЁ - больше здесь нифига нет! Ну, кое-какие проблемы с передачей данных - деньги всё-таки, "безопасность", панимаш! А вот если туда впендюрить и DLL, и ОС, и .NET, всё это хорошенько палкой перемешать, изуродовать язык со страшной силой... тогда разработчикам будет обеспечен фронт работ на долгие годы.    

Виталий, Так ведь хрень вполне себе стейбл!    

swerg, А что ещё делать остаётся?   Управление теряется, прерывания идут как бог на душу положит, с типами данных полная задница, например:
iT=tonumber(GetCell(T,p1,0).value); - скрипт вылетает, причём даже не хрюкает - смотрю, а он уже полчаса как стоит, а вот
iT=tonumber(GetCell(T,p1,0).image); - пока работает.
Ну и куча других аналогичных "мелочей". Я ведь писал когда-то, прямо в этой ветке - как чувствовал:
4. Я считаю (лучше сказать "надеюсь"), что прерывание OnTrade НЕ МОЖЕТ "потеряться" и придти после того, как пришла информация о другой сделке по той же заявке, а потому...
Зря надеялся.    

Как оказалось, я страдал чрезмерным оптимизмом: мало того, что прерывания OnOrder и OnTrade приходят пачками (что, конечно, есть форменное свинство и должно быть исправлено), так они ещё приходят и вразнобой! По крайней мере, когда одна заявка реализуется через нескольких сделок: сначала приходит OnTrade с ID заявки и ID сделки, затем с ID заявки и ID ВТОРОЙ сделки, а затем с ID заявки и снова, падла. с ID ПЕРВОЙ сделки! В результате мой алгоритм думает, что сделок совершено больше, чем в действительности. Ну руки бы пообрывал таким программерам! И что мне теперь, держать инфу обо всех сделках до конца сеанса и бегать по ним по всем - вдруг она уже обработана? УЖАС, господа! Столько версий расплодилось - НУ ХОТЬ ЧТО-НИБУДЬ БЫ работало по-человечески!

Виктор, Архивы торгов ведутся во многих местах - например, вот архив акций, торгующихся на СПб - отсюда я качал минутные свечи за полгода чуть не по тысяче тикеров (когда отлаживал свой алгоритм): http://mfd.ru/export/?groupId=33

А сейчас я и вообще свечи считаю сам (в прерываниях по таймеру), на небольших временных интервалах (до часовых, кажется), но мне больше и не требуется.

nikolz, Секрет. Алгоритм у меня свой, и (тьфу-тьфу!) очень хороший.

На исторических данных я работал до июня, и это было довольно утомительно. Да, "сделки будут разные", но только потому, что там у меня были минутные свечи (собссно, только цена закрытия), а сейчас я ориентируюсь на цену последней сделки из getParamEx. И я больше не гоняю исторические данные, ибо точно знаю: алгоритм - тот же (с некоторыми улучшениями по результатам работы).

Виктор, Задавайте имена полей таблиц как натуральные числа и не мучайтесь. У меня весь скрипт так построен - и нет проблем. Вот, например, оператор аж из двойного цикла:
if a[i][8][j]~=0 then k=CF[a[i][9][j]+5];

Anton, Нет, есть и третий вариант: использовать по максимуму имеющееся говно. Что , собссно, и сделал.    

Вам не лень фигнёй заниматься, господа? Управление теряется, сраная интерпретируемая функция способна подвесить весь квик, а вы тут с "финализаторами-деструкторами" маетесь, да с collectgarbage воюете. НУ НЕ МОЖЕТ эта хромоногая кляча нормально работать, здесь ИДЕОЛОГИЧЕСКИХ плюх до мамы! Да, делать какие-то телодвижения в OnStop - это маразм, но там, по крайней мере, файлы прекрасно открываются, закрываются и записываются. А что ещё требуется для торгового скрипта?

TGB, Я вовсе не "наезжаю на Lua" - меня язык полностью устраивает. В смысле, язык-то поганый, но я уже реализовал на нём всю необходимую мне функциональность - осталось мелкая шлифовка, но это уже в фоновом режиме, не горит. И мне нафиг не нужен C++, тем более, что я его терпеть не могу, и всю жизнь писал на чистом С. Но для этих задач и С не нужен - есть Lua, и даже его здесь вполне достаточно.

swerg, Я уже просил (не помню, Вас или нет): не надо врать! Это про "не читает документацию". А как передаются параметры в Lua, мне АБСОЛЮТНО до лампады - я не разработчик языка, я просто пользователь. Просто ЕСЛИ они передаются не ссылкой, а самой таблицей значений, ТО это есть идиотизм. Идиотизм тех, кто ПИШЕТ эту самую "документацию".

Anton, Что за зверь trie? Префиксное дерево, что ли? Так ведь ЛЮБОЙ набор данных можно представить либо в виде массива (например, байт) - в этом случае должен быть известен его размер, либо в виде строки - в этом случае нужно знать значение терминатора. В обоих случаях нужно знать место начала этого набора (адрес или лучше UID). Да и какие могут быть "нюансы" в несчастном дереве? Данные в реальности куда более сложно организованы и могут быть представлены только графом общего вида.

s_mike@rambler.ru, Ну это ещё как посмотреть, у кого словоблудие.  

Я чуть не всю жизнь занимался сложными базами данных, и утверждаю, что ЕСТЬ "в базе данных терминала адреса строки или чего то ещё, описывающей сущность". По той простой причине, что доступ к любому элементу данных ДОЛЖЕН быть обеспечен.

Никто и не просит "передать адрес этой сущности" - это даже для СУБД недопустимо! Ну, в крайнем случае, для ядра СУБД, если "уж замуж невтерпёж". Но вот обеспечить корректную работу с UID (для разных уровней доступа они могут быть разными) любая уважающая себя СУБД просто ОБЯЗАНА!

Квик написан БЕЗОБРАЗНО - примеров тому несть числа, а потому говорить о его хранилище как о базе можно разве что в ироничном ключе.

В луа нет даже целочисленных типов данных - какое уж тут "прямое лазанье по памяти указателем". Да и ни один уважающий себя разработчик такого не позволит.

Охотно верю, что "квалификации разработчиков терминала вполне достаточно, чтобы правильно решать тривиальные вопросы типа "передать ссылку или значение", но вот вопрос: а они её ПЕРЕДАЮТ? Или всё-таки " заполняют табличку"?

Anton, Если индекс понимать как здесь - по виду индекс, по факту имя - то именно так всё и будет. И глюки при удалении строк или сортировке таблицы как неизбежное следствие. А если это UID, то никто ничего никогда никуда не подвинет. Идиотизм - копировать юзеру всю колоду данных вместо того, чтобы дать ему один этот UID - и пусть читает по нему, чего хочет. Временные затраты при этом просто РАВНЫ нулю! Подумаешь, "хранилище асинхронное"...

Anton, В этом! Хранилище по определению асинхронное. И информацию о сделках Квик всё равно хранит у себя. Так что можно просто передать указатель на запись (ну или хотя бы индекс записи) и не объяснять потом пользователям ничего, поскольку программа должна быть нормально отлажена. А уж "смотреть при старте скрипта на сигнатуру колбека и не заполнять табличку, если она ему не нужна" - это в морг! И так уже затрахали своим долбаным интеллектом - достаточно посмотреть хотя бы на эту долбаную "таргетированную рекламу".

Anton, Серьёзно?! Ох, как прав был Лавров...

Anton, А нафига? Последний оператор в работе скрипта - пущай сами деструктурируют.  

А ООП-религия у меня сложилась давно, ещё от Маккарти. И не всяким Страуструпам её поколебать!    

Anton, И что бы это значило?    

Да указатель он передаёт - что ему, заняться больше нечем, кроме как "табличку упаковывать"? Впрочем, я уже ничему не удивлюсь. Лично я убил коллбек OnOrder и оставил только OnTrade, а цены опрашиваю примерно раз в секунду через getParamEx. ИМХО, самое разумное.

Николай, Это ко мне вопрос? Никак - у меня нет срочного рынка ваапще. Да и ликвидная стоимость мне, по большому счёту, не нужна. Но какие проблемы посчитать? Цена покупки известна, цена последней сделки тоже (или, если угодно, цена спроса и предложения). Так что цена, если мы продадим "вот прям ща" тоже известна...

Anton, Может, и Винда - она написана не менее коряво, чем Квик. Впрочем, фиг с ними обоими - у меня сейчас идёт финальная зачистка уже моего алгоритма - все "квиковские" штучки считаю отлаженными. Последняя правка была вчера: как известно, эта скотина теряет управление при остановке скрипта, поэтому файл результатов я записываю прямо в OnStop (благо запись не обращается к утилитам основного потока), а теперь там же стал ещё и убивать окно своей таблицы. Окно-то она убивает, "зато" влетает в режим этого дурацкого ожидания, так что теперь у меня OnStop возвращает 500, чтобы не мучился свои 5 секунд, и для юзера это (аварийное) завершение смотрится как нормальное. Комедия!

"С:\Quik1" , "C:\Quik2" и есть абсолютный путь.   У меня тоже два Квика, но путает папки вовсе не Lua (там у меня как раз относительный путь типа F=io.open(getScriptPath().."//datafile.txt","r"), а сам Квик: при нажатии кнопки "добавить" при загрузке скриптов он открывает не папку "своего" Квика, а ту, из которой была последняя загрузка.

Старатель, Нет такой возможности. У меня  контекстное меню (оно же QLua таблица) вызывается как раз по QTABLE_RBUTTONDOWN, но своё меню она ТОЖЕ рисует. Видимо, перехват событий под свои нужды средствами Lua в принципе невозможен - свои обработчики эта скотина всё равно вызывает.

Сделал глобальной в мейне таблицу заявок: Tr={};
Инициализацию изменил, соответственно, на:
Tr.TRANS_ID=tostring(k);
Tr.ACTION="NEW_ORDER";
...
Заявка (по команде из всплывающего меню) прошла и даже исполнилась, "зато" теперь по OnOrder (отлов этой заявки) ругается на "attempt to concatenate a nil value (field 'CLIENT_CODE')". Раньше не ругалась. Я где-то читал, что CLIENT_CODE - необязательный параметр, но без него она у меня заявки не принимала. А теперь чего ей надобно? Может, имя поля какое другое? Может, она мне взад уже не отдаёт код клиента? Нет, не может - раньше ведь работало! Уффф! Большой перекур!    

О, сколько нам открытий чудных!..  

Syntax error while compiling C:\QUIK\my.lua 237: "goto q"  at line 205 jumps into the scope of local "Tr"

Такого я ещё не видывал нигде и никогда! Ну да, заполняемая таблица заявки у меня описана как
local Tr={
["TRANS_ID"]=tostring(k),
["ACTION"]="NEW_ORDER",
---

Но метка-то, блин, стоит ПОСЛЕ неё! Ладно, сделаем глобальной - авось, сожрёт...  
 

Artem, Винде это дело глубоко по барабану.  У меня на этом компе тоже семёрка-64. И у меня, кстати
message (d0("76054.000000"));
даёт строго 76054

Это, скорее всего, такой формат выдачи - что-то типа %1.5f. Нули многих раздражают, включая меня, и именно здесь, на форуме, и было подсказано это решение. Я его завернул в функцию и активно пользуюсь, замечаний не имею. Правда, я не помню, был ли у меня случай, чтобы нули были и справа и слева от точки. Впрочем, проверим... нет, и
message (d0("76520.000000"));
даёт строго 76520.

А на техподдержку не надейтесь - это уж точно не их вопрос.

Artem,

Artem, Разбиралось здесь уже. И код утилиты, убирающей концевые нули, не раз приводился.

swerg, Ну да ну да... советчиков с растопыренными пальцами, "объяснявших", что 2 и "2" это разные вещи, было как собак нерезаных. а вот если головой подумать требуется...

Да выгребусь уж как-нибудь. С диалогом выгреб, а с подачей заявок да приходом квитанций и подавно.

А вот фигушки вы угадали! Пытаюсь программно продать одну акцию (в смысле, 1 лот) ВТБ у брокера ВТБ и получаю: "Превышен общий лимит кредитования". При этом деньги у меня ЕСТЬ, акции у меня ЕСТЬ, вручную Квик спокойно это дело продаёт. А при попытке продать акции, купленные за доллары или за евро и вообще выдаёт "неверная цена". Цена, блин, ВЕРНАЯ! Всё передаётся в заявку в строковом виде. При этом по рыночной цене ("0") эта скотина спокойно продаёт! Чиорт побъери, ну как с этим со всем можно работать?

Ну что, так никто ничего и не посоветует?   Ведь заявки со сделками - это ЕДИНСТВЕННОЕ, что должно быть в ЛЮБОМ роботе, и потому этот механизм должен быть вылизан до блеска! Вплоть до включения его в язык. Ладно, излагаю то,  что я вижу сам, что собираюсь завтра реализовывать, когда биржа откроется.

1. Скрипт просто посылает заявку на покупку или продажу (sendTransaction) и никак не отслеживает это дело у себя - ведь то же самое может сделать и юзер.

2. О факте существования [зарегистрированной] заявки (от кого бы она ни исходила) скрипт узнаёт по приходу прерывания OnOrder, и тогда регистрирует её у себя. Предполагаем, что заявок может быть несколько на каждый тикер, т.е. это таблица Lua, в которой ключом является код заявки, а значением - код сделки (которое мы вначале обнуляем). В принципе, сюда же можно занести количество лотов и цену - на всякий пожарный.

3. Поскольку прерывания OnOrder, как и OnTrade, здесь приходят "пачками" (заявки у меня обычно вызывают два прерывания, сделки - три), то следующие прерывания OnOrder с тем же кодом просто игнорируем (если это не снятие заявки - в противном случае убиваем элемент таблицы заявок).

4. Я считаю (лучше сказать "надеюсь"), что прерывание OnTrade НЕ МОЖЕТ "потеряться" и придти после того, как пришла информация о другой сделке по той же заявке, а потому держу для каждой заявки только ОДНО поле для (текущей) сделки. Если оно приходит впервые - запоминаю его код по ключу текущей заявки и произвожу по ней действия по изменению своего портфеля и кошелька.

5. Если заявка полностью выполнена (или снята) убиваю заявку в скрипте - все необходимые действия уже произведены.


Кактотаг...

Я имею в виду "режим кентавра", когда робот торгует параллельно с юзером. Как обрабатываются возможные конфликты? Мои соображения такие.

0. Главный здесь юзер, у него на торговлю нет никаких ограничений.

1. Скрипт должен быть в куре всех действий юзера (и своих, разумеется) и ловить их по прерываниям OnTrade и OnOrder.

2. Я не уверен, что OnTrade вообще нужно обрабатывать - ведь OnOrder в этом случае всё равно должен придти - по нему, похоже, и можно всё посчитать.

3. Скрипт я вижу "одноразовым" - он не должен посылать заявок по данному тикеру, если не обработаны все предыдущие (пофиг, от робота или от юзера).

4. Сами заявки хранятся у брокера, а не в скрипте и даже не в Квике. С другой стороны, подавляющее большинство заявок (по крайней мере, МОИХ заявок), должны бы обрабатываться немедленно (я выставляю цену покупки или продажи соответствующим образом), и потому о них можно забыть сразу после исполнения, т.е. хранить именно в теле скрипта - от первого до последнего OnOrder.

Одним словом, я не знаю, как всё это дело лучше организовать. А кто-нибудь знает?

Sergey Denegin, Элементарно, Господи! И не нужно никаких "два цикла со sleep". Вот кусок main:

А вот эмулятор обработчика:КТО ИМЕННО "полностью прекращает свою работу и просто ждет это время"? Скрипт? Так это просто интерпретируемый текст - он вообще никогда не работает.    

swerg, Я не помню, какие там две последние цифры, но ругается и на goto и на метки - проверено вчера. Сам Квик был скачан с сайта ВТБ тоже буквально на днях - я скачивал намного раньше, но раза два или три потом обновлял.

Anton, Не знаю, но Ваше мнение для меня не менее интересно, чем мнение сотрудников арки.