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

Anton, ВСЮ?! Нет, я-то уж точно об этом не договаривался!   Не знаю, что там за "кооперативная модель", но у интерпретатора (точнее, при любом программировании данными) может быть ТОЛЬКО модель вытесняющая, иначе это не интерпретатор, а говно. Концепция не менялась, она вообще родом из прошлого тысячелетия!

Да, "мы получаем эмулятор некого процессора", и этот процессор РАБОТАЕТ! Я же сказал, "зачем" - для возможности программирования данными! Любой интерпретируемый язык - это именно программирование данными в девственно чистом виде.

Anton, Да никаких действий! Пусть себе решает! Интерпретатор же просто квантует время и периодически что-то там ему выполняет "в свободное от работы время". Ну, может сказать: "Эй, чувак! Твой обработчик уже полчаса молотит! У тебя ничего не случилось"?

Именно! И на процессоре никакая не многозадачность! Вот если более одного ядра, тогда да, а так для IP эти "опкоды" именно "всего лишь пассивные байты, которые сами ничего не умеют" - это для него ДАННЫЕ! Это очередь данных. А вместе с SP это стек очередей тех самых пассивных данных". А потому, огранизовав аналогичный стек на данных и запрограммировав интерпретацию команд некоего подмножества ассемблера, мы получаем возможность почти полноценного программирования данными, которые могут располагаться даже во внешних файлах (в частности, в теле БД).

Ничего подобного! В луа loadfile НЕ ЕСТЬ "конструктор объекта функция"! Да, в интерпретаторе (теоретически) можно даже динамически склепать тело функции в переменной (это же просто строка!) и вызвать потом эту переменную как функцию, но в реальной жизни интерпретатор почему-то обычно боится это делать - как и в случае с goto имеем кастрирование возможностей программиста.

Anton, Правильно предполагается! Интерпретатор и "работает в неком контексте и по неким "прерываниям" переключает контекст на зарегистрированный обработчик, дает ему доработать до победного и переключает контекст обратно". Это никакая не "многозадачность" - работает ТОЛЬКО интерпретатор, а сами скрипты есть просто пассивные куски кода, голый текст, который сам делать ничего не умеет.

ЕСЛИ "юзер решил порешать задачу коммивояжера в обработчике" и ИЗ-ЗА ЭТОГО "вся система встала колом", ТО гнать надо поганой метлой разработчиков такого "интерпретатора"! Не надо никого "прибивать" - в некоторых моих задачах (генератор сайтов или обработка баз данных) часть аналогичных скриптов вообще А ФАЙЛАХ лежат, и "асинхронно снять его контекст на полпути и потом снова в него войти" как два пальца об асфальт! Да чего далеко ходить - в этом самом моём скрипте на Lua часть кода находится именно во внешних файлах, и исполняется, как будто он набит в теле программы (loadstring) - и прекрасно работает! И никаких "неожиданных изменений в окружении" не происходит".

Разумеется, этот пример допустимый! И скрипт должен напечатать "123". Мейн в этой технологии ТОЧНО ТАКОЙ ЖЕ обработчик прерываний! Включается по запуску, выключается по Wait и снова получает управление по останову. Грубо говоря, утром включили, вечером выключили, а всё это время его НЕТ. Где хранилась переменная? В контексте скрипта. Ведь обработчики тоже пользуются не только своими локальными переменными! И при чём тут ваще "ось"? Какие могут быть "потоки" у интерпретатора? Точнее, у интерпретатора-то они теоретически могут быть (хотя и ему они, по большому счёту, нафиг не нужны), но у интерпретируемых им сраных текстов... Какой "шедулер", какие "свои стеки", какая "синхронизация" - побойтесь Бога!

Вот именно, что НЕ ДОЛЖЕН "тот пустой объект "уметь: а) рождаться (конструктор); б) умирать (деструктор); в) опционально клонироваться"! НЕ ДОЛЖЕН! Пустой объект - значит ПУСТОЙ! Какой Вы предлагаете "конструктор" для объектов класса "функция"? Вот именно: НИКАКОЙ! А что собрались оттуда "наследовать"? Вот именно: НИЧЕГО! А исключениям и вообще место только на помойке!

swerg, Внимательнее ответ стоит прочитать.   main - это ТОЖЕ обработчик, и никакого отношения к многопоточности не имеет.

OnStop - это при нормальной организации НЕ ЮЗЕРОВСКАЯ функция, а системная. Так что нужно просто послать сообщение "убей меня". А можно и не посылать: main закончился - интерпретатор знает, что нужно делать. По крайней мере, ДОЛЖЕН знать!

НЕ БЫВАЕТ "модели без main()"! При запуске скрипта ЧТО-ТО должно начать выполняться. Вот это "что-то" и есть main, хоть горшком её назови.

Anton, Не, Я - не встречался! И игрушка моя, кажись, единственная (шахматы), и вообще любая прога с событиями (т.е. 99% всех моих программ) отсутствие событий никаким событием не считают. А на события только отвлекаются, прерывая свою "деятельность бурную".  

Что значит "солнце вручную закатывать"?! Интерпретатор нарывается на Wait, ставит В СВОЙ OnStop операцию возврата управления, И ЗАБЫЛ НАФИГ ПРО ЭТОТ СКРИПТ ВААПЩЕ! Только по прерываниям передаёт управление зарегистрированным там обработчикам (естественно, никакого "сканирования" для этого не требуется). Какая разница, на каком там ядре что выполняется? Нашего потока в этом случае тупо НЕТ! И до Винды, кстати, тоже никакого дела нет.
Ну да, ну да - теперь пойдёт у нас уж музыка не та, у нас запляшут лес и горы!(С)  

Нет, лично я убеждён, что делать низшей единицей надо именно ПУСТОЙ объект! РЕАЛЬНО пустой, а не тот, который "умеет прорисовывать себя на экране, реагировать на события" и ещё какую-то хрень делать, не помню уже. От такого объекта тупо НЕЧЕГО наследовать.

swerg, Так сказали же, вроде: по OnStop сбросить все заказанные обработчики и отдать управление в main.

Anton, Э, нет! Этот wait на практике будет реализован как передача управления основному потоку, и выполняться он будет именно там (при нажатии кнопки "Стоп" (OnStop вообще недоступен юзеру) вернёт управление в main, к следующему за Wait оператору - разница принципиальная!

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

С лёгкой руки Билла Гейтса, объект обработки сообщений, как правило, называют окно. Поскольку ОС Windows является одной из самых популярных систем, в которой реализована, хорошо отлажена и документирована технология работы с сообщениями, мы будем сравнивать наш подход именно с ней. При изложении концепций SINT мы будем использовать близкие по смыслу термины меню и событие соответственно.

Anton, А что тут определять? Переменные - это ЕГО переменные, пусть делает с ними, что хочет. Критический момент тут может быть разве в том случае, если пришло ещё одно прерывание, а он не успел обработать это, но такая ситуация ловится тривиально.

2) А с какого бодуна "они обе в мейне будут асинхронно выполняться"? При такой технологии код мейна должен быть примерно такой:
То есть main производит какие-то телодвижения при запуске скрипта, настраивает обработчики и ОТДАЁТ управление, которое передастся в этот поток уже по прерываниям, конкретному обработчику, вроде MyHandler:

А по нажатию кнопки останова ВЕРНЁТ управление мейну (вылетит из  Wait и пойдёт выполнять что там дальше написано). Чего, кстати, как Вы подсказали, она сейчас как раз и не делает (точнее, делает, но не всегда).А вот это спорный вопрос!    Вот фрагмент из моей книги:

На наш взгляд, принятая в среде Windows двухшаговая модель обработки сообщений идеологически непригодна для программирования в событиях. Мало того, что этот сервис относится (в терминологии SINT) к аппаратному уровню и, следовательно, обеспечивает переносимость кода разве что с Windows95 на WindowsXP. Куда более серьёзным возражением является то, что при таком подходе программирование в событиях представляет собой всего лишь замаскированное операторное программирование. Действительно, первичный обработчик каждой очереди сообщений Windows раздаёт их адресатам, у каждого из которых имеется собственный (вторичный) обработчик. Такой подход имеет сразу несколько весьма неприятных следствий. Во-первых, при отправке сообщения необходимо заранее знать адрес (дескриптор) получателя, хотя на момент отправления события адресат может вообще не существовать. Во-вторых, обезличенность событий позволяет программам иметь единственный обработчик «на все случаи жизни», а всю информацию, специфицирующую объекты реакции на события, вынести в виртуальные обработчики, т.е. в данные, которые могут находиться как внутри тела программы, так и вне его. Кроме того, большинство меню пользователя имеют один и тот же обработчик даже на уровне данных (управление курсором, клавиши Enter, Esc). Программистом такой «обработчик по умолчанию» вообще не указывается – это дело конструктора соответствующего меню. Специализированные обработчики обычно перехватывают нескольких специальных событий, а обработку остальных наследуют от более универсальных.

Ещё более неприятное следствие подхода Windows состоит в том, что приходится прилагать значительные усилия, чтобы позволить программам свободно обмениваться сообщениями друг с другом или внешними устройствами, и в то же время максимально изолировать приложения, чтобы крах одного из них не вызвал крах других или всей системы. Это синхронизация очередей сообщений, контроль их доставки, перемещений внутри потоков, обработка аварийных ситуаций. Например, что делать с сообщениями, если окно-адресат закрывается? Ответ нелегко дать даже в философском плане. У Windows очередь таких сообщений просто сбрасывается. В технологии SINT диспетчер посылает текущее событие всегда текущему активному обработчику. Это позволяет направлять группу событий сразу многим обработчикам, при этом часть событий может быть предназначена для переключения обработчиков, осуществляя своего рода навигацию по ним. Под управляющим воздействием этой группы обработчики могут рождаться, обрабатывать предназначенные им события и умирать, передав остаток необработанных событий очередному обработчику.

У нас пока не возникало необходимости программирования многозадачных приложений, хотя техническая возможность создания нескольких процессов в рамках одного приложения имеется, и даже не очень сложна в реализации. Следует лишь помнить, что методы класса "функции" работают на одном и том же программном стеке, и при переключении процессов следует заботиться о сохранении и восстановлении данных этого стека. Внутри же одного процесса обработка событий в SINT также имеет радикальные отличия от той же Windows, касающиеся приоритетов. В обоих случаях обработка обычно происходит в порядке поступления (очередь). Что же касается асинхронных (срочных) событий, мы полностью отказались от управления последовательностью их обработки с помощью приоритетов: любое событие, даже имеющее наивысший приоритет, всегда можно при необходимости обогнать. Это принципиально невозможно для Windows, где обработчик срочных сообщений вызывается напрямую, и до окончания его обработки никакое другое сообщение не может быть обработано. Таким образом, объект реакции на событие не может иметь класс "группа событий", что создает колоссальные трудности при программировании диалога (в SINT более половины всех объектов диалога принадлежат именно этому классу).

Anton, А ЧТО ИМЕННО он может "не увидеть"? Если юзер ковыряется в своей песочнице - ему и не надо ничего видеть, пусть ковырется на здоровье. А если вдруг собрался выполнить что-то "недозволенное" - схватит его за руку.

Anton, Как это "никто не знает"?! Это же ИНТЕРПРЕТАТОР! Он же САМ исполняет функции юзера, в том числе, и код колбеков! Всё должно быть под полным контролем! Интерпретация - самый крутой тип исполнения программы в плане надёжности.

Anton, Почему "путь в адъ"? Путь в рай!  

Хочет мейн событиев - регистрирует колбек, который будет вызываться из второго потока, а обрабатываться "в его же контексте", а для этого на входе должна быть только регистрация обработчика, и никто никого не должен "периодически дергать". В УПОР не вижу здесь "способа быстро убиццо апстену".  

TGB, Идеологически всё правильно: поток main - это поток юзера, второй поток - поток Квика, и, следовательно, они должны обмениваться данными именно механизмом обработки событий, а юзера "своими грязными лапами" в основной поток пускать нельзя. А sleep и есть "служебная функция ожидания", но ни в коем случае не "либо появления данных в очередях событий" - события есть аналог прерываний, и sleep есть аналог прерываний по таймеру, которые не должны перекрываться другими событиями. Хотя, конечно, вместо этого цикла с анализом флага isRun (это тоже флаг Квика, а не юзера!) разумнее иметь что-то типа Wait(), выход из которой осуществлялся бы по OnStop (и эта функция не юзеровская идеологически - его дело давить на кнопки "Остановка скрипта", а не обрабатывать своё же событие), а управление юзер получал бы по OnTimer(Nms). То есть имеем две очереди событий, от скрипта к Квику и наоборот, обе обслуживаются Квиком, при этом события для юзера вызывают соответствующие функции их обработки (OnTrade, скажем), а события от юзера передаются функциями, и не SendEvent, а более "приземлёнными" - SetCell, SetOrder (а не жутко выглядящая sendTransaction), etc. Но ведь это совсем другой язык, другая технология, так что я согласен с фразами про "мечтателей".    

Роман, Кого позвать?   Лично я абсолютно нихрена не понял, что Вы, собственно, хотите сделать.

swerg, Врать - нехорошо   Это насчёт "не читает". Что до другого тезиса, так я давным-давно (в начале "нулевых" писал:

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

Nikolay, Что "это"? Техника записи результатов без риска потери управления? А что же все молчали, включая техподдержку, когда мы с Антоном и другими это дело обсуждали в нескольких ветках?    

Олег, Кажется, я придумал, как решить проблему с записью в файл и, одновременно, убрать дико раздражающую меня необходимость анализа флага останова при любом обращении к функциям второго потока (тем более, что это не гарантирует отсутствие потери управления). Делаем так:
Запись результатов в файл производим после каждой сделки - ведь состояние портфеля изменилось, фиксируем новое текущее. В самом прерывании OnTrade это делать "неприлично" (ещё что-нибудь может придти), поэтому там просто устанавливаем флаг необходимости перезаписи файла, а саму инфу кидаем в стек сделок. А уже в нашем прерывании (по таймеру) разбираемся с этим стеком, записываем результаты и сбрасываем флаг. А по выходу из main как раз ничего в файл не пишем - актуальное состояние уже записано, и плевать на потерю управления или даже неожиданное отключение питания! Просьба покритиковать - мне эта идея ОЧЕНЬ понравилась. И на код теперь не так тошно глядеть.

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

Александр, Я пишу не Вам. И давно.

Александр, Я уже отвечал на это. А также говорил: что и как мне делать, я всегда решаю САМ!

Александр, Ну это ещё вопрос, у кого из нас понос.   Мне как раз НРАВИТСЯ оператор goto, о чём я здесь 100500 раз проговорил открытым текстом. Мне не нравится эта кастрированная пародия на goto, о чём я тоже говорил открытым текстом. Мне не нравится эта долбаная "динамическая типизация", мне не нравится, что скрипт мой до сих пор иногда теряет управление при останове, хотя я буквально все обращения во второй поток обвистовал анализом флага останова (и сама необходимость такого анализа мне тоже не нравится). И вообще, "интегральная" оценка здесь неуместна: мне ОЧЕНЬ нравится наличие loadstring, возможность построения дерева объектов, сервис для работы с файлами и ещё кое-что по мелочи. Но это не значит, что должно быть "либо-либо": есть конкретные недостатки языка, конкретные недостатки реализации, их можно и нужно исправлять!

Никто никому ничего не должен. Я неоднократно имел возможность убедиться, что Антон - программист очень высокой квалификации, и хотел бы услышать его рекомендации. Его, а не Ваши, если уж совсем честно.

Олег, Алгоритм-то оин, но он довольно сложный: ведь он зависит не только от инструмента, но и от состояния рынка, состояния собственного кошелька, возможности (или невозможности) освободить средства для покупок и ещё от чего-то там.

Олег, Не, лучше правило "один скрипт - ДОХРЕНА инструментов! У меня на оном Квике несколько десятков инструментов, на втором - несколько сотен. А скрипт фактически один (с небольшими модификациями). Ну ладно, пусть два.    

Угу.

Рассказали бы мне лучше, что там надо читать по OnTrade. Я вижу, что она правильно возвращает price, qty и sec_code, а больше мне, кажись, ничего и не надо. Что там нужно контролировать? Кроме того, я тут краем уха видел жалобы, что прерывание это может приходить неоднократно или вообще не приходить. И, заодно, как посылать заявки. Ну и, до кучи, чем ловить и как обрабатывать события от юзера.

Anton, Стек - это LIFO, очередь - FIFO. Комбинируя их, получаем возможность программирования данными. Аналог: регистр IP выполняет команды по очереди, а прыгает - по стеку (SP, CALL). Здесь то же самое, только на данных. А на плюсах функциональнуть НИ НА МИЛЛИМЕТР не выше, чем в чистом С, только маразмов разных понасовано, вроде деструкторов с эксепшенами.

Да без проблем! Вот кусок кода (переключатель по классу методов)\Эта конструкция вызывает любую (зарегистрированную) функцию с любым числом и типом аргументов.

NP-полную? Ну вот как раз сейчас у меня два графа на двух компах считаются на задачу коммивояжёра - один на 10 миллионов узлов, второй на 50. Одна на выданье (дня три считала, думаю, через пару часов закончит), второй еще пару недель трудиться в поте лица.    

Александр, НА КОЙ мне, простите, стек Lua? Равно как и стек процессора? Ни тот, ни другой мне нафиг не нужны. Я просто сказал, что goto в Lua - это не оператор, а говно, и пользоваться им не имеет смысла. Сказал буквально в двух строчках одного коммента! А плотом пошла бурная "дискуссия", да ещё временами с гнутыми пальцами. Я-то здесь при чём? Не лучше ль на себя, кума, оборотиться?

Anton, Ну... у меня не раз бывало по 5-6 стеков на задачу, и ни одного по SP/ESP/RSP. Да, у потока именно ОДИН стек (у меня обычно стек очередей), и в каждой очереди свой указатель + указатель вершины стека. Для неоднородных стеков чуть сложнее.

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

Олег, Видимо, можно и в одном, но зачем? Одновременность уж точно пропадёт! К тому же, у меня к этим брокерам доступ разный. Alt+Tab - и все дела!    

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

swerg, А Вы не мучайтесь - Вы скажите. Раз по делу сказать нечего.  

Я не понимаю, что такое "торговая система", но у меня нет ни малейших сомнений, что такие данные надо хранить у себя. И не в файле, а в ОЗУ (при запуске читая из файла, а при останове сбрасывая туда текущее состояние). А изменяться оно должно, как я понимаю, по OnTrade (как раз сейчас ковыряюсь в этом направлении - прерывания при сделках уже приходят, но что там они приносят, нужно долго разбираться). У одного брокера у меня два счёта. а у другого - несколько валют, инструменты вполне могут пересекаться в любой момент. Лично я сделал так: каждому брокеру завёл свой "персональный" Квик, а внутри одного веду отдельный подсчёт, где ключом является код инструмента, код класса и код моего счёта. Нареканий нет...

Anton, Да какая разница? Я ещё 20 лет назад писал (про исключения): ""Секундочку! У меня раньше сомнений не возникало, а сейчас что-то появились: объекты - они что, на стеке ПРОГРАММЫ генерятся???"

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

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

Вот это как раз и называется "снять дамп извне", ибо это МОЯ задача, и операционка В ПРИНЦИПЕ ничего о ней знать не может, кроме своего сраного "состояния регистров". ПАСПОРТА надо записывать, буферы файлов сбрасывать, очереди событий (точнее, стеки очередей) сохранять (точнее, тамошние курсоры) и т.д.

Anton, При чём тут ТЕКУЩИЙ стек, если мне надо отложить ВСЮ задачу, ВСЕ его стеки, ВСЕ рекурсивные штучки-дрючки? И запустить я её могу, может быть, через год, и на другой платформе - всё авно всё должно работать как часы! И при чём тут вообще регистры? Вы НА ПРОГРАММНОМ стеке собираетесь всё это проделывать? Который по SP? Спасибо, кушайте сами!    

Anton, Нет, coroutine - это совсем другое. О, Господи! В ЛУА???!!! Нет уж, в луа я как-нить файлами обойдусь: логом (для юзера) и выходным (для компа). А моим "лисапедам" уже десятки лет, отлажены, вылизаны почти до блеска - здесь-то уж точно в гробу я видел творения сторонних разработчиков! Вон, разобранная Вами проблема потери управления между потоками чего стоит! Не говоря уже о 19-значных кодах.

Ха! НА КАКОМ, простите, стеке? А если у нас НЕСКОЛЬКО стеков (в частности, некоторые объекты могут иметь персональные стеки) - тогда как?

Какие ещё "исключения"?! Нет у меня никаких исключений! Нет, не было и не будет! Нигде и никогда!    

Nikolay, Почему "не изучив"? Я сначала обрадовался наличию goto в языке, а потом как посмотрел...

Ну, если "он не работает в блоках", то поганой метлой! Я так и сказал.

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

Нет уж, С ТАКИМ goto я писать не буду!  

Да, "внутрь блока if, while" - серьезно. Представьте, что у Вас многочасовая, многодневная задача. Вы должны иметь возможность в любой момент отложить её, и потом возобновить работу с отложенного места. А если там штук пять вложенных циклов? Или, прости Господи, вообще рекурсия? Я совершенно точно знаю, что goto с такими проблемами прекрасно справляется. А вот как обойтись БЕЗ него - лично я без понятия! А здесь у меня даже в мыслях не было, что этот оператор здесь кастрированный. У меня файл входных данных парсится, там в разных местах возможны разные ошибки в данных, некоторые из них критичные - я в таких случаях ругаюсь на юзера и закрываю скрипт. Проверок много, проверки разные, а реакция - одна, и она именно "блочная". И тут БАЦ - и полный облом! А если на группу разных проверок есть группа разных реакций? Короче, в морг!    

swerg, Так программы ПО ФУНКЦИОНАЛУ СВОЕМУ бывают посложнее!   Не только торговые погремушки. Скажу больше: без входа внутрь блоков if или внутрь циклов goto И В САМОМ ДЕЛЕ нафиг не нужен. В частности, вот это убожество: кто его использует - поднимите руки!

swerg, Вот он я "такой программист". 40 лет вхожу внутрь блоков if, и горя не знаю   Программы бывают чуть посложнее, чем a=b+c;    

Александр, Ваша эрудиция приводит меня в трепет.    Только вот нюансик: goto и нужен именно для того, чтобы входить внутрь блоков if! Или выходить из колоды вложенных циклов. Или, наоборот, входить туда. А этот кастрат кому и на кой сдался?

И при чём тут вообще стек? Lua - это ИНТЕРПРЕТАТОР! Это только кривые ручонки, а не "стековый скрипт".

Я уже говорил тыщу раз: я СПРАВЛЮСЬ даже на этом языке, ибо требования к торговому софту просто НУЛЕВЫЕ. Ну, оказался полным говном goto - выбросить придётся к чертям собачьим - только и всего.    

Александр, А что тут "разбираться"? Этот придурок не пускает внутрь блока if - что у меня, что в вашем примере.

Ах, паскуды! Мой любимый goto оказался с изъяном: внутрь блока if-then не пускает (метки не видит). Ну ручонки бы повыдёргивать этим долбаным "умникам"!    

Anton, Спасибо, понял.

Anton, Я бы ещё одну штуку хотел узнать - недавно столкнулся: частичное исполнение заявок. Дело было так: заявка в выставленные на продажу 50 лотов исполнялась несколько часов. Исполнялась, исполнялась, да так и не исполнилось - на момент закрытия биржи 4 лота остались непроданными, и заявка (по факту почти исполненная) получила статус "снята". Мне показалось (не уверен - там ещё и другие сделки были), что в течение этого времени количество свободных средств у меня увеличивалось после каждой сделки (частичной продажи). Я знаю, что в момент подачи заявки на покупку резервируются деньги на её исполнение, а при продаже - соответствующее количество акций. Но вот что происходит в процессе исполнения - я пока не врубился. Короче, вопрос такой: в какой момент освобождаются блокированные ресурсы?

Anton, То есть файловые операции не держат? А что же формат не вызывает напрямую сишную sprintf?    

Александр, Во-первых, файловые операции - это минус порядок по сравнению с ОЗУшными, так что тормозит тут не язык, а файл. Во-вторых, у Lua есть хронический недостаток: вместо индексов используются ключи, а это ещё порядок.

Денис, Нет, я не разработчик QUIK, но и не так, чтобы "просто проходил мимо". Я пользователь - теперь уже и Lua, и разработчик собственных скриптов на нём.

0. Я написал ровно то же самое, почти дословно.  
1. УПС! Это же всего лишь ВИЗУАЛИЗАЦИЯ, блин! У меня ПРИ ЛЮБОЙ сортировке обеспечен доступ К ЛЮБОЙ ячейке, ВНЕ зависимости от того, в какой строчке таблицы она сейчас находится! НЕ НУЖНО "запретить возможность делать сортировку, чтобы данные всегда были на своих местах" - нужно просто правильно к ним обращаться!
3. Мне тоже "не нравится такой костыль", но хоть как-то работает.
4. Ха-ха-ха! Я чуть ли не всю свою сознательную жизнь занимался сложными базами данных, даже книгу про это написал. И много раз "мочил в сортире" этот убогий "деревянный" XML, не говоря уже про JSON.

Денис, Ну, флаг в руки. а не поделитесь, ЗАЧЕМ нужны 20 скриптов? Просто для общего развития.   У меня вот и один скрипт вполне обеспечивает и диверсификацию (как горизонтальную, так и вертикальную) и количественный трейдинг...

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

1. Таблицу "доступные скрипты" лучше хранить на отдельной вкладке - там она никому не мешает.
2. После запуска скриптов её вообще можно удалить. А если не останавливать скрипт при закрытии Квика, он и вообще запустится автоматически.
3. Лично у меня в "Загруженных скриптах" только ОДИН скрипт. Иногда два (рабочий и тестовый). Кому и зачем нужно больше - не понимаю.    

Занятное предложение от Антона - я как раз наоборот, использовал Эксель до знакомства с Луа, и отказался от него буквально в первую же пару дней после него - "таблица, созданная с помощью CreateWindow" оказалась намного информативнее. А сейчас у меня и вообще набор строк динамически обновляется, а сами ячейки раскрашиваются чуть не во все цвета радуги - тоже динамически.

1. Не понял. По умолчанию таблица выдаётся в том же порядке, в каком добавлялись строки (InsertRow). Что тут "отключать"?

2. Ячейка-то всегда доступна для редактирования (SetCell), а вот сам редактор... неплохо бы обсудить большую тему "организация диалога на Lua" - техника отлова событий, стандартные утилиты реакций на них и т.п.

12. Без понятия, но лично я склепал статус-бар в заголовке таблицы (SetWindowCaption)

13. Зачем "по каждой"? Только по нужным.    

TGB, Ну... я бы тоже не отказался от С-подобного синтаксиса (например, JS), но искать что-то лучшее стал бы только при нехватке функциональности, а она тут вполне терпимая.

Anton, Да, ассемблер и машинный код - это одно и то же, только записанное на разных языках. И jmp, он же goto, там имеется, ибо без него полная труба.

Я всегда пишу именно "в чистых сях", и goto не только "не страшен" - он полезен! А Страуструп, как и Вирт, нифига не понимали в программировании.  

swerg, Нет, мне нужен именно одновременный доступ. Причём у одного брокера у меня несколько счетов, у другого несколько валют, а тикеры у них иногда частично пересекаются. Я просто не подумал раньше - никакая "левая" отладка не заменит настоящую...

swerg, Спасибо, посмотрю. Если я правильно понимаю, для этого мне нужно запустить третий Квик (два моих Квика настроены на двух моих брокеров, и менять эти настройки я не хочу - тем более, что оба брокера дают доступ к Московской бирже в "боевом" режиме).

О, Господи, какая громоздкая регистрация! Нет, пожалуй, я буду отлаживать это дело прямо в боевом режиме, на малых суммах.