[[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга

Поддержка
  • @senerg said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    работающих вылеченных аналогов

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

    botnet
    https://community.bablosoft.com/topic/5261/я-плачу-весь

  • Интересно, что ответ так и не дали. Я решил проблему так - записываю CYCLE_INDEX в другую переменную, после этого задержка, и после вложенного цикла возвращаю номер обратно в CYCLE_INDEX .

  • @sten30 said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    Интересно, что ответ так и не дали.

    Я первым же сообщением дал корректный ответ

    90260a62-c4d4-4d4b-b3bf-794944c4ab41-изображение.png

    Я решил проблему так - записываю CYCLE_INDEX в другую переменную, после этого задержка, и после вложенного цикла возвращаю номер обратно в CYCLE_INDEX .

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

  • @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

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

    Тут есть небольшая проблема.

    Если в кастомном модуле в функции есть цикл, то код из кастомного модуля затрет переменную CYCLE_INDEX в коде пользовательского скрипта своим значением.

    С другими подобными переменными такая же проблема.

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

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

    Выглядит жутким хаком.

    Если кому то надо, вот список глобальных переменных, не всех их надо сохранять и восстанавливать.

    VAR_CYCLE_INDEX
    VAR_FOREACH_DATA
    VAR_FOR_EACH_CSS
    VAR_FOR_EACH_MATCH
    VAR_FOR_EACH_XPATH
    VAR_WAS_ERROR
    VAR_LAST_ERROR
    VAR_ERROR_ID
    VAR_CYCLE_INDEX
    VAR_FOREACH_DATA
    VAR_FOR_EACH_CSS
    VAR_FOR_EACH_MATCH
    VAR_FOR_EACH_XPATH
    VAR_WAS_ERROR
    VAR_LAST_ERROR
    VAR_ERROR_ID
    

    Общую идею, как это можно делать, можно почитать тут:
    https://community.bablosoft.com/topic/25851/проблема-при-вызове-функции/30

  • @sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

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

    Тут есть небольшая проблема.

    Если в кастомном модуле в функции есть цикл, то код из кастомного модуля затрет переменную CYCLE_INDEX в коде пользовательского скрипта своим значением.

    С другими подобными переменными такая же проблема.

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

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

    Выглядит жутким хаком.

    Проблема переменных BAS в модулях имеют более глобальные последствия, ведь многие используют в действиях стандартные названия переменных, а затем из этих действий создают модули, которые и вызывают проблемы перезаписи переменных со стандартными названиями. Об этой проблеме уже есть тикет, есть несколько возможных решений, но пока единственный надёжный способ, это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)

  • @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    проблема переменных BAS в модулях имеют более глобальные последствия

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

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

    Хотя логика простая - если до вызова функции некий список переменных был объявлен(CYCLE_INDEX, VAR_FOREACH_DATA, etc), то перед вызовом функции сохранять их значения и восстанавливать после возврата.

    Вот прямо сейчас я это и делаю на основании твоего же кода.

    P.S.
    У модулей должен быть своя видимость области переменных, это решит почти все проблемы.

  • @sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    проблема переменных BAS в модулях имеют более глобальные последствия

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

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

    Хотя логика простая - если до вызова функции некий список переменных был объявлен(CYCLE_INDEX, VAR_FOREACH_DATA, etc), то перед вызовом функции сохранять их значения и восстанавливать после возврата.

    Вот прямо сейчас я это и делаю на основании твоего же кода.

    P.S.
    У модулей должен быть своя видимость области переменных, это решит почти все проблемы.

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

  • @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    Не уверен, что область видимости можно ограничить в BAS

    Пользователям нельзя, разработчику думаю можно все.

    @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

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

    Кстати идея, задумался не написать ли мне сейчас скрипт, который делает post-process модуля, превращая все переменные внутри функции модуля в случайные названия.

  • @sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    Пользователям нельзя, разработчику думаю можно все.

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

    Кстати идея, задумался не написать ли мне сейчас скрипт, который делает post-process модуля, превращая все переменные внутри функции модуля в случайные названия.

    Да, я вроде даже выкладывал скрипт для замены имён переменных в модуле, не помню только где именно.

  • @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    Да, я вроде даже выкладывал скрипт для замены имён переменных в модуле, не помню только где именно.

    @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)

    Если в файле engine.js заменить все переменные, которые начинаются с VAR на что-то другое, то это пройдет без побочных эффектов?

    было:

    VAR_LOG_PREFIX = _function_argument("_log_prefix")
    
    var json = JSON.parse(native("filesystem", "fileinfo", VAR__DIRECTORY_PATH))

    
    VAR_FILEINFO_EXISTS = json["exists"]
    
    

    стало:

    _LOG_PREFIX = _function_argument("_log_prefix")
    
    var json = JSON.parse(native("filesystem", "fileinfo", __DIRECTORY_PATH))

    _FILEINFO_EXISTS = json["exists"]
    
  • @sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    это в ручную править код заменяя переменные BAS на переменные js (var VAR_CYCLE_INDEX и т.д.)

    Если в файле engine.js заменить все переменные, которые начинаются с VAR на что-то другое, то это пройдет без побочных эффектов?

    было:

    VAR_LOG_PREFIX = _function_argument("_log_prefix")
    
    var json = JSON.parse(native("filesystem", "fileinfo", VAR__DIRECTORY_PATH))

    
    VAR_FILEINFO_EXISTS = json["exists"]
    
    

    стало:

    _LOG_PREFIX = _function_argument("_log_prefix")
    
    var json = JSON.parse(native("filesystem", "fileinfo", __DIRECTORY_PATH))

    _FILEINFO_EXISTS = json["exists"]
    

    По идее должно работать, однако вы меняете одни глобальные переменные js на другие.

  • @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    По идее должно работать, однако вы меняете одни глобальные переменные js на другие.

    Было "VAR_", стало без него.

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

    Или надо var VAR_Buu и таким обзором они станут локальными javascript переменными ?

  • @sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    По идее должно работать, однако вы меняете одни глобальные переменные js на другие.

    Было "VAR_", стало без него.

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

    Я об этом и говорю, смысл в том, что к переменным модуля можно будет получить доступ извне. Если цель обезопасить пользователя от замены существующих переменных, то достаточно добавить длинную случайную строку (можно unixtime для уникальности добавить). Это будет более безопасно, чем удолять VAR_

  • @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    Я об этом и говорю, смысл в том, что к переменным модуля можно будет получить доступ извне. Если цель обезопасить пользователя от замены существующих переменных, то достаточно добавить длинную случайную строку (можно unixtime для уникальности добавить)

    На всякий случай уточняю еще раз.

    Было:

    VAR_LOG_PREFIX = _function_argument("_log_prefix")
    

    Стало:

    Вариант 1:

    var VAR_LOG_PREFIX = _function_argument("_log_prefix")
    

    Вариант 2:

    VAR_LOG_PREFIX_some_string_name_of_module_for_example = _function_argument("_log_prefix")
    

    Вариант 3:

    var VAR_LOG_PREFIX_some_string_name_of_module_for_example = _function_argument("_log_prefix")
    

    По идее, второй вариант можно встроить в генератор модулей.

    Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
    И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff.

  • @sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    По идее, второй вариант можно встроить в генератор модулей.

    Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
    И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff.

    Да

  • @Fox said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    @sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    По идее, второй вариант можно встроить в генератор модулей.

    Тогда у пользователя останется возможность даже обратится к переменной модуля, если он захочет.
    И в git не будут светиться лишние изменения, так как нет ничего случайного и нет мусорных diff.

    Да

    Так я и сделаю у себя, пока напишу скрипт для замены.

    Огромное спасибо, что подсказал все варианты, что могут быть.

  • @sergerdn said in [[CYCLE_INDEX]] в двух циклах FOR вложенных друг в друга:

    Так я и сделаю у себя, пока напишу скрипт для замены.

    Скрипт оказался мега-простой, замена в одну строчку, пропускаю код, где подготавливаются переменные:

    module_replace_vars:
    	@echo "Replacing variables in engine.js for $(MODULE)..."
    	@sed -i 's/\(VAR_[A-Z_]\+\)/\1__$(MODULE)/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
    	@echo "Variable replacement complete for $(MODULE)."
    

    Запускаю как:

    make module_replace_vars MODULE=MyModule1
    make module_replace_vars MODULE=MyModule2
    

    Результат работы:
    Capture.PNG

  • @Fox

    Выяснилось, что в кубике Browser / Javascript не поддерживаются переменные вида:

    [[SomeCamelCase]]
    

    А только вида:

    [[FORTRAN_CASE]]
    

    Соответственно нужно заменять переменные не на NameOfModule, а на NAME_OF_MODULE.

    Иначе получаем ошибку в кубике Browser / Javascript :

     ReferenceError: SERP_DATA__MyModule is not defined
    

    Ну и надо некоторые служебные переменные исключить из замены.

    Итого я заменяю так:

    
    # Function to convert to screaming(BAS) snake case
    define to_screaming_snake
    $(shell echo $(1) | sed -E 's/([^A-Z])([A-Z])/\1_\2/g' | tr '[:lower:]' '[:upper:]')
    endef
    
    module_replace_vars:
    	@echo "Replacing variables in engine.js for $(MODULE)..."
    	@sed -i 's/\(VAR_[A-Z_]\+\)/\1__$(MODULE_SNAKE_CASE)/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
    	@sed -i 's/\([[\([A-Z_]\+\)]]\)/[[\2__$(MODULE_SNAKE_CASE)]]/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
    	@sed -i 's/VAR_LAST_ERROR__$(MODULE_SNAKE_CASE)/VAR_LAST_ERROR/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
    	@sed -i 's/VAR_ERROR_ID__$(MODULE_SNAKE_CASE)/VAR_ERROR_ID/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
    	@sed -i 's/VAR_WAS_ERROR__$(MODULE_SNAKE_CASE)/VAR_WAS_ERROR/g' "$(MODULE_DST_DIR)/$(MODULE)/$(MODULE)/engine.js"
    	@echo "Variable replacement complete for $(MODULE)."
    
    # Call module_prepare_vars before module_replace_vars in the dependency chain
    module_replace_vars: module_prepare_vars
    
    # Prepare the module name variable
    module_prepare_vars:
    	$(eval MODULE_SNAKE_CASE := $(call to_screaming_snake,$(MODULE)))
    	@echo "Variable preparation complete for $(MODULE_SNAKE_CASE)."
    

  • 0 Votes
    2 Posts
    296 Views
  • 0 Votes
    1 Posts
    371 Views
  • 0 Votes
    4 Posts
    1533 Views
  • 0 Votes
    8 Posts
    1735 Views
  • 0 Votes
    36 Posts
    24319 Views