Изменить версию Lua с 5.4.1 до 5.4.2

Страницы: 1
RSS
Изменить версию Lua с 5.4.1 до 5.4.2
 
Поскольку известно, что в Lua 5.4.1 есть неприятный баг

https://www.lua.org/bugs.html#5.4.1-1

https://forum.quik.ru/messages/forum10/message51162/topic6053/#message51162

исправленный в Lua 5.4.2, имеет смысл поднять версию внутри QUIK.
 
Заходит пациент в кабинет к доктору.
-- На что жалуетесь?
-- Доктор, меня все игнорируют.
-- Следующий.


https://forum.quik.ru/messages/forum10/message51220/topic6053/#message51220
 
Существует ненулевая вероятность, что сборщик придёт как раз во время обхода таблицы в одном из потоков.
Скрытый текст
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Этот тест воспроизводит ошибку? Если да, то разработчикам, всё-таки, стоит зарегистрировать пожелание.
 
В Lua 5.3 и Lua 5.4:
Цитата
invalid key to 'next'
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, добрый день!

Правильно понимаем, что при работе данного скрипта:
Цитата
Старатель написал:
local p = {}
function OnParam(class_code, sec_code)
 p[sec_code] = class_code
end

local t = {}
function OnAllTrade(alltrade)
 t[alltrade.sec_code] = alltrade.class_code
end

function main()
 while run do
   for k, v in pairs(p) do
     p[k] = nil
   end
   for k, v in pairs(t) do
     t[k] = nil
   end
   sleep(1)
 end
end
С некоторой вероятностью может появиться следующая ошибка?
Цитата
Старатель написал:
invalid key to 'next'
У себя подобного за целый день не увидели, можете предоставить снимки экрана?
 
Цитата
Roman Azarov написал:
С некоторой вероятностью может появиться следующая ошибка?
Верно

Цитата
Roman Azarov написал:
У себя подобного за целый день не увидели
Можете форсировать события:
Скрытый текст
и сделать перезаказ всех обезличенных сделок.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Чтобы обход таблицы был более корректным, изменим тестовый скрипт, так, чтобы добавление и удаление полей таблицы осуществлялось в одном потоке:
Скрытый текст

Ошибка "invalid key to 'next'" никуда не делась.
Для форсирования: перезаказать все обезличенные сделки.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
На самом деле, при использовании в боевом скрипте внутри цикла pairs, ещё много операций, а иначе зачем он нужен?  :lol: Типа:
Код
for sec_code, class_code in pairs(p) do
  p[sec_code] = nil
  local last = tonumber(getParamEx2(class_code, sec_code, "LAST"))
  ...
end
И тогда ошибка возникает практически сразу (без форсирования).
В таком случае, чтобы избежать ошибки, таблицу лучше обходить через next.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
QUIK 8.13.1.16, Lua 5.4
Получил очередную ошибку
Цитата
invalid key to 'next'
в древнем скрипте
Код
local ID = {}
function main()
  ...
  for TableName, id in pairs(ID) do
    ID[TableName] = nil
    DestroyTable(id)
  end
  ...
end
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Старатель написал:
QUIK 8.13.1.16, Lua 5.4
Получил очередную ошибку  
Цитата
invalid key to 'next'
в древнем скрипте
Код
   local  ID  =  {}
 function   main ()
   .. .
   for  TableName, id  in  pairs(ID)  do 
    ID[TableName]  =   nil 
     DestroyTable (id)
   end 
   .. .
 end   
с функцией next проблемы давние, в 5.3 тоже присутствуют.
 
Придётся вот таким "изящным" способом обходить:
Код
repeat
  local k, v = next(t)
  if k == nil then break end
  t[k] = nil
until false
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Если у вас колбеки могут изменять столы, то нужно пользоваться потокобезопасными функциями.
 
Цитата
Артем написал:
нужно пользоваться потокобезопасными функциями
Хотелось бы увидеть пример потокобезопасной функции для обхода ассоциативного массива. Или вы предлагаете весь цикл в ssort запихать?

Не знаю, какие "столы", но с сообщения #8 работа с таблицей - в одном потоке. Впрочем, это по коду видно.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, ходить по массиву можно обычными функциями, а удалять/добавлять значения надо потокобезопасными. Вообще, удалять значения из массива в цикле по этому же массиву это плохая практика; вы тут судя по всему просто очищаете стол, вместо этого можно просто создать пустой - это не только надежнее и проще, но еще и работает быстрее.
 
Цитата
Артем написал:
удалять/добавлять значения надо потокобезопасными
Какой, например, функцией для ассоциативного массива? И почему?
Цитата
Артем написал:
удалять значения из массива в цикле по этому же массиву это плохая практика
Цитата
Артем написал:
просто создать пустой - это не только надежнее и проще
Можете обосновать каждое своё утверждение?
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, sinsert sremove.


То что небо голубое мне тоже обосновать? Я понимаю что если вы живете в пещере то вам это неочевидно, но всё же.
 
Цитата
Старатель написал:
для ассоциативного массива
Цитата
Артем написал:
sinsert sremove

Ну ляпнули вы ерунду один раз. Зачем дальше-то показывать свою глупость?
К вам вопросов больше не имею.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, посты тех кто жалуется на язык читаю про диагонали.


https://lmgtfy.app/?q=lua+remove+from+table+in+loop

https://forum.quik.ru/forum10/topic5294/
Очистить стол - N операций вм и N операций гц. Заменить пустым - 1 операция вм и N+1 операций гц.

То что вам поенепременно надо использовать  непотокобезопасные методы в многопоточной программе - тут что называется  своих мозгов в чужую голову не вставишь.
 
Цитата
Артем написал:
удалять значения из массива в цикле по этому же массиву это плохая практика
В Lua не запрещено, из Reference Manual:
Цитата
The behavior of next is undefined if, during the traversal, you assign any value to a non-existent field in the table. You may however modify existing fields. In particular, you may set existing fields to nil.

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

Цитата
Артем написал:
Очистить стол
Столы - в мебельном. А здесь - таблицы, и в таблице могут очищаться не все значения:
Код
for k, v in pairs(t) do
  if exp then t[k] = nil end
end
Создавать новую таблицу под каждое очищаемое значение - это бред.

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

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

Цитата
Артем написал:
а кто-то берет и обосновывает
Что вы там обосновали? Про "небо голубое"? Аргументов от вас лично я так и не увидел.

Цитата
Артем написал:
просто не работайте с одной и той же памятью из разных тредов
Спасибо, кэп, без вас бы не разобрались.
Ветка про другое. Второй поток вообще может не знать про таблицу в первом, или может знать, но не работать с ней.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Цитата
Roman Azarov написал:
У себя подобного за целый день не увидели

Roman Azarov, вот тест, который воспроизводит ошибку практически сразу после перезаказа обезличенных сделок.
Скрытый текст
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Тем временем, в Lua 5.4 продолжают находить баги. Так что если разработчики, всё-таки, будут обновлять версию, то просьба до самой последней обновить.
https://www.lua.org/bugs.html#5.4.3
 
Баги были есть и будут. Тут есть два подхода: постоянно обновляться до самой свежей версии, в процессе чего что-то может сломаться, либо выбрать версию и сидеть на ней всё обозримое будущее, а с багами люди разберутся на месте.
 
Старатель, добрый день!

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

На данный момент проблема изучается. Постараемся в ближайшее время дать ответ.
 
Цитата
Старатель написал:
Цитата
Roman Azarov написал:
У себя подобного за целый день не увидели

Roman Azarov, вот тест, который воспроизводит ошибку практически сразу после перезаказа обезличенных сделок.
    Скрытый текст       Можете поиграться со значением параметра n
Код
   local  n  =   25 
 local  run  =   true 
 function   OnStop ()
  run  =   nil 
 end 

 function   OnParam (class_code, sec_code)
  p  =  {}
   for  i  =   1 , n  do 
    p[tostring(i)]  =  tostring(i)
   end 
   for  k, v  in  pairs(p)  do 
    p[k]  =   os.time ()
    p[k]  =   nil 
   end 
 end 

 function   OnAllTrade (alltrade)
  a  =  {}
   for  i  =   1 , n  do 
    a[tostring(i)]  =  tostring(i)
   end 
   for  k, v  in  pairs(a)  do 
    a[k]  =   os.time ()
    a[k]  =   nil 
   end 
 end 

 function   main ()
   while  run  do 
    m  =  {}
     for  i  =   1 , n  do 
      m[tostring(i)]  =  tostring(i)
     end 
     for  k, v  in  pairs(m)  do 
      m[k]  =   os.time ()
      m[k]  =   nil 
     end 
     sleep ( 1 )
   end 
 end   
Добрый день,
     
      Действительно, в ПО QLUA есть ошибка функций обратного вызова       скрипта приводящая к подобным ошибкам. Мы справим её в очередном       обновлении ПО приносим извинения за причинённые неудобства.
Страницы: 1
Читают тему (гостей: 1)
Наверх