Роберто начал над версией 5.4 работать пару недель назад. Новый сборщик мусора планируется.

5.1 навеки останется актуальной версией :)

Отсюда и delay или sleep.

Любая асинхронщина работает на event loop, где мы бесконечным циклом проверяем поступление новых событий и выполняем соответствующие колбеки. Тут действительно нужен слип, чтобы приложуля не жрала 100% проца на ожидании новых событий. Но есть много вариантов получить крошечный слип (в зависимости от оси), и оформить это маленькой милойи функцией.

Ну тут слип с ожиданием все таки... То есть если поступает сигнал - все просыпается. Ну или ничего не пришло - что-то делаем и опять в ожидание.

Ну тут слип с ожиданием все таки... То есть если поступает сигнал - все просыпается. Ну или ничего не пришло - что-то делаем и опять в ожидание.

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

плохой слип ))))

Я ставлю слип на секунду, а все просыпается через 1.5? )))

Я ставлю слип на секунду, а все просыпается через 1.5? )))

Да, именно так :3 Но ты ставишь слип на .0001, а ось просыпает твое приложение как только может, но после этого времени.

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

увы, у луа есть проблемы с сигналами. я пробовал и отступился, ибо можно было иначе, без сигналов решить.

А кто-нибудь из присутствующих имел дело с Lua в NodeMCU?

Я, но немного. Обычная луа, только с либой gpio. Можно извратиться и подключить флешку с кодом, увеличивая размер программы до бесконечности, подгружая и удаляя модули из оперативки.

Мне вот интересно, 0.9мс на один опрос gpio-ноги это потому что реализация Lua хреновая или потому что контроллер такой слабый?

Да там и штатной памяти на 1-4 Мб за глаза хватает.

Мне вот интересно, 0.9мс на один опрос gpio-ноги это потому что реализация Lua хреновая или потому что контроллер такой слабый?

Нога стоит на input, и ты просто делаешь serial.read?

Ага, только, наверное, gpio.read.

С записью в порт то же самое, кстати.

Из-за этого без сишной либы вывод на текстовый lcd экран дико ториозит.

Косяк с таймаутами.

А что за таймауты?

Ну, когда ты считаешь с ноги строку - нужно некоторое время подождать, пока строке не придет полностью, если она длинная.

какая строка, одно считывание гпио ж один бит

Да я просто пин читаю, без символов и всего этого.

да и чтение из символьного буфера обычно тоже быстренькое. как в уартах

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

Сэкономили в плане объема кода.

Да куда там ещё экономить, по идее там функции тривиальны. Разве что надо преобразовать условный номер пина в его фактическое расположение.

А работа с таблицами не может тормозить?

Можешь попробовать обновить прошивку, авось пофиксили.

Может, но слабо, и совсем не на 100мс.

Скинь код на pastebin

http://pastebin.com/1EP5fixy

Тайминги замерял снаружи лог.анализатором

Попробуй заменить до цикла self.pins['E'] переменной

Ага, надо будет попробовать.

Но один фиг, не хардкодить же номера пинов в либе

ну это понятно, но хотя бы будет более понятно, что затык не в этом

dev.test = function(self) local write, high, low = gpio.write, gpio.HIGH, gpio.LOW write(self.pins['E'], HIGH) Чуть-чуть ускорит за счёт кеширования, и писать короче.

@Snusmumriken обнаружил ошибку в твоей гномьей сортировке.

Именно в сортировке? Чегось там?

вместо local i, j = 2, 3 while i < #t do надо local i, j = 2, 3 while i <= #t do

<= #t

Понял, понял. Хм. Сейчас думаю на что это влияет. Последний элемент не сортируется?

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

да

А, да, тогда ты прав = )

Так было задумано? )))

Конечно :3 Кому нужны скучные, правильные алгоритмы, которые делают всё как надо.

ну блин ) В общем поправляй где-там надо

Уже, спасибо за фидбек

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

??

Люди делают ошибки, и это делает их людьми. Перечитал ницше, и теперь грызу ногти от ужаса, что я не сверхчеловек. Хе-хе-хе

Стань киборгом

Alejandro: Бакалавры и Магистры! Кто хочет в Google Summer of Code 2017 попасть? Пишите в личку.

Добро пожаловать в чат pro.lua, Vadim! Ознакомься с правилами чата (в описании и прикрепленном сообщении), и присоединяйся к обсуждению.

Alejandro: Бакалавры и Магистры! Кто хочет в Google Summer of Code 2017 попасть? Пишите в личку.

А если я никто можно ли мне попасть в Sputnik Summer of Code 2007?

2007? Кто-то изобрел уже машину времени??? ))))))))))))

Ну думаю надо узнать, у организаторов, по поводу лета кода. Хотя вроде как это для студентов

Спутник тебя и во времени, и в пространстве перенесет при желании

Добро пожаловать в чат pro.lua, Alexey! Ознакомься с правилами чата (в описании и прикрепленном сообщении), и присоединяйся к обсуждению.

Потестил всякие оптимизации на NodeMCU, результат следующий: Если в строке gpio.write(self.pins['E'], gpio.HIGH) заменить self.pins['E'] на переменную, то скорость остаётся той же. Если в строке gpio.write(pin, gpio.HIGH) заменить gpio.HIGH на переменную, то скорость возрастает в 2 раза Если потом заменить ещё и gpio.write на переменную, то получается прирост в 18(!) раз.

ERROR: S client not available

Если после всего этого обратно вернуть self.pins['E'], то получаем замедление в 1.2 раза. Видимо, на большой скорости обращение к этой таблице становится уже заметно.

Кешируем и пляшем. Карочи, объясняю для тех кто плохо помнит, как происходит поиск переменных. Простой пример: t = {key = 'yo'} -- 0 function foo(x, y, z) -- 1 for i = x, y do -- 2 z = z + 1 print(t.key) end end Цифрами обозначены области видимости. Каждый раз когда мы ищем t.key, мы сначала проверям на наличие таблички t область видимости 2 (содержимое цикла), ничего там не находим, ищем в области видимости 1 (функция), не находим, спускаемся в табличку _G, и внезапно находим там t. Прогоняем в ней ключ key в хеш-функции, и внезапно снова находим значение 'yo'. В результате, n = (y - x) раз, мы раз за разом проверяем эти области видимости, чтобы каждый раз найти эту самую табличку t с ключом key. Это не шибко круто, поэтому добавив ссылку на табличку перед циклом (а лучше - сразу дублировать ключ, если он не изменяется в процессе цикла), мы сокращаем время поиска раза в два (поиск в цикле - неудачный, поиск в функции - удачный), такие дела. Да, чем "глубже" находится объект поиска, тем медленнее поиск, думаю это очевидно. Со ссылками на (функции/таблицы) в таблицах, мы получаем ещё больше плюх, ибо они передаются как ссылки (не тратится время и оперативка на дублирование значения), и отсутствует даже поиск внутри таблички-батьки, поэтому замена gpio.write на local write = gpio.write даёт больше преимуществ, хоть и незначительно грузит сборку мусора: советую не плодить много переменных/таблиц в длинных циклах: инициализировал всё что нужно перед циклом, и обрабатывай на здоровье. Аналогично с gpio._LOW / gpio._HIGH: залокалили и нет поиска. А вот с тестами - молодец, старайся как бенчмаркать даже казалось бы обычные вещи. P. S. Прирост в 18 раз - не предел. Можно больше. С luajit ты бы получил прирост производительности в 150-400 раз, если бы загнал функцию в цикл, но увы, из-за объёма оперативки (jit имеет оверхед на разогрев трасс и их компиляции), его скорее всего не будет в nodemcu. И ты можешь сказать спасибо что это не жаваскрипт/питон, потому что чтобы оптимизировать подобное там - нужно знать гораздо больше, ибо под капотом происходит реально много неочевидных и костыльных вещей.

Всё, спать. Приятных тем, кого я разбудил уведомлялкой.

Добро пожаловать в чат pro.lua, Alex! Ознакомься с правилами чата (в описании и прикрепленном сообщении), и присоединяйся к обсуждению.

Спасибо за объяснение. Правда, всё равно не понял, почему при замене gpio.write прирост в 18 раз, а при замене gpio.HIGH - только в 2. Сейчас глянул, на ноде gpio представляет собой romtable с вот таким содержимым: > for k,v in pairs(gpio) do print(k.." => "..tostring(v)) end mode => lightfunction: 40253a54 read => lightfunction: 40253a08 write => lightfunction: 402539b0 serout => lightfunction: 40253b28 trig => lightfunction: 402538cc INT => 2 OUTPUT => 1 OPENDRAIN => 3 INPUT => 0 HIGH => 1 LOW => 0 FLOAT => 0 PULLUP => 1 По идее, если там идёт линейный поиск, то функцию write найти проще, чем константу HIGH.

Хз ))) Надо отдельно смотреть или влезть в сурцы gpio. P.S. Функцию write найти так же затратно, как константу HIGH. Только запоминается ссылка на неё (типа указатель), а не значение.

Я так понимаю, запомнить ссылку должно быть дешевле, чем значение?

А не, это я туплю. Доступ к gpio.HIGH тоже в 18 раз дороже его отсутствия, просто в совокупности с доступом к gpio.read профит получался всего в два раза.

Ну, в общем на выходе довольно неплохо. Кеширование = хорошо, ты понял.

Кешируем и пляшем. Карочи, объясняю для тех кто плохо помнит, как происходит поиск переменных. Простой пример: t = {key = 'yo'} -- 0 function foo(x, y, z) -- 1 for i = x, y do -- 2 z = z + 1 print(t.key) end end Цифрами обозначены области видимости. Каждый раз когда мы ищем t.key, мы сначала проверям на наличие таблички t область видимости 2 (содержимое цикла), ничего там не находим, ищем в области видимости 1 (функция), не находим, спускаемся в табличку _G, и внезапно находим там t. Прогоняем в ней ключ key в хеш-функции, и внезапно снова находим значение 'yo'. В результате, n = (y - x) раз, мы раз за разом проверяем эти области видимости, чтобы каждый раз найти эту самую табличку t с ключом key. Это не шибко круто, поэтому добавив ссылку на табличку перед циклом (а лучше - сразу дублировать ключ, если он не изменяется в процессе цикла), мы сокращаем время поиска раза в два (поиск в цикле - неудачный, поиск в функции - удачный), такие дела. Да, чем "глубже" находится объект поиска, тем медленнее поиск, думаю это очевидно. Со ссылками на (функции/таблицы) в таблицах, мы получаем ещё больше плюх, ибо они передаются как ссылки (не тратится время и оперативка на дублирование значения), и отсутствует даже поиск внутри таблички-батьки, поэтому замена gpio.write на local write = gpio.write даёт больше преимуществ, хоть и незначительно грузит сборку мусора: советую не плодить много переменных/таблиц в длинных циклах: инициализировал всё что нужно перед циклом, и обрабатывай на здоровье. Аналогично с gpio._LOW / gpio._HIGH: залокалили и нет поиска. А вот с тестами - молодец, старайся как бенчмаркать даже казалось бы обычные вещи. P. S. Прирост в 18 раз - не предел. Можно больше. С luajit ты бы получил прирост производительности в 150-400 раз, если бы загнал функцию в цикл, но увы, из-за объёма оперативки (jit имеет оверхед на разогрев трасс и их компиляции), его скорее всего не будет в nodemcu. И ты можешь сказать спасибо что это не жаваскрипт/питон, потому что чтобы оптимизировать подобное там - нужно знать гораздо больше, ибо под капотом происходит реально много неочевидных и костыльных вещей.

#lua #fyi #namelookup

Ага.

помощ помощ понемногу пытаюсь переехать на Atom щас поставил git-plus что б напрямую работать с гитом из атома но там как то все тяжко идет со скрипом есть у кого внятные мануалы для курения по этому поводу до этого пользовал гит десктоп понимаю что консоль мощнее но просто лень

Насчет Атома не в курсе, но по гиту полно манов на хабре. например: https://habrahabr.ru/post/313890/

https://habrahabr.ru/post/174467/

Пользовал sourcetree. Это конечно если я правильно понял вопрос ) Или как работать с гитом в Атоме?

А что в git-plus со скрипом?

Есть ещё плагин, называется, ЕМНИП, git-control. Там графический интерфейс открывается во вкладке Атома.

Тут я не знаю, этих инструментов не использовал. Ждем других )

Source tree и github предпочитаю тоже. Не люблю коммитить из редактора.

Зачем нужен атом, если есть сублим?

атом оч.хорошо кастомизируется ну и проприетарщина не нужна

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

атом оч.хорошо кастомизируется ну и проприетарщина не нужна

Сублим тоже. А вся его проприетарщина заключается в нажимании эксейпа раз в час

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

так это для холиваров про C++ же

Да там можно и про иде

Сублим тоже. А вся его проприетарщина заключается в нажимании эксейпа раз в час

В Атом тоже можно такую фичу встроить, от этого он не станет проприетарным. Это про другое совсем.

В Атом тоже можно такую фичу встроить, от этого он не станет проприетарным. Это про другое совсем.

Не понял предложение)

Не понял предложение)

Тоже можно сделать окошко "купи лицензию".

Тоже можно сделать окошко "купи лицензию".

Всё ещё не понял, к чему это

К тому, что проприетарность и периодическое нажатие Escape друг с другом не связаны.