ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / C++ [игнор отключен] [закрыт для гостей] / Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
25 сообщений из 184, страница 1 из 8
  1  все
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574009
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlekseySQL
Гость
Насколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).

Делал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?

Есть ли какая- то книжка, статья, блог, канал youtube... где о подобном скрещивании можно почитать подробненько?

Благодарю за обмен опытом!
...
Рейтинг: 0 / 0
21.12.2017, 19:20
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574016
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
AlekseySQLНасколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых
языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).

Ты уверен, что не наоборот?..

Если хочешь - вбей в гугль "1С" и хоть зачитайся. Там, правда, не питон, но тоже
скриптовый язык.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.12.2017, 19:41
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574039
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlekseySQL
Гость
Dimitry Sibiryakov, на 1с программировал примерно 13 лет... Но я не про многопользовательские СУБД, где скорость работы отдельного пользователя не важна (поэтому, кстати, в 1с нет и никогда не будет многопоточности). Да, в таких случаях и прикладную часть реализуют на скриптовом языке.

Если же скорость работы приложения важна, то основной расчет реализуют на языках низкого уровня. Например, в том же python библиотеки написаны на языке С, чтобы шевелилось побыстрее. На вскидку могу предположить, что подобный подход позволяет быстро создать прототип приложения, который потом можно будет оптимизировать с помощью низкоуровневого языка в нужных местах.
...
Рейтинг: 0 / 0
21.12.2017, 20:52
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574042
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
AlekseySQLНапример, в том же python библиотеки написаны на языке С, чтобы шевелилось побыстрее. На
вскидку могу предположить, что подобный подход позволяет быстро создать прототип
приложения, который потом можно будет оптимизировать с помощью низкоуровневого языка в
нужных местах.

Так работает любой скриптовый язык - от PHP до LUA. И да, библиотеки для питона пишутся на
С не от хорошей жизни и даже не чтобы шевелилось быстрее, а потому что иначе никак. Не
могут скриптовые языки ни с чем взаимодействовать без нативной прокладки.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.12.2017, 21:04
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574044
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
AlekseySQLЕсли же скорость работы приложения важна, то основной расчет реализуют на языках низкого уровня. Например, в том же python библиотеки написаны на языке С, чтобы шевелилось побыстрее. На вскидку могу предположить, что подобный подход позволяет быстро создать прототип приложения, который потом можно будет оптимизировать с помощью низкоуровневого языка в нужных местах.
Проблема в том, что любое приложение должно иметь ядро, которое, в том числе, будет порождать процессы (нити) и управлять ими. И это ядро так же является высоконагруженной частью приложения, и, желательно, его сразу иметь на компилируемом языке.
Отсюда и возникает конструкция вроде 1С или Axapta. Есть скомпилированное ядро, если скриптовый язык, который может использовать как скомпилированные компоненты ядра, так и внешние компоненты, в том числе и скомпилированные.
Иными словами, интерпретатору отдается средний слой, тогда как верхний и нижний остается прерогативой компиляторов.
Такой подход как раз и позволяет легко оптимизировать что угодно, вынося это на нижний слой, без ущерба верхнему слою, который сразу компилируемый.
...
Рейтинг: 0 / 0
21.12.2017, 21:10
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574070
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlekseySQL
Гость
ptr128Проблема в том, что любое приложение должно иметь ядро, которое, в том числе, будет порождать процессы (нити) и управлять ими. И это ядро так же является высоконагруженной частью приложения, и, желательно, его сразу иметь на компилируемом языке.
Отсюда и возникает конструкция вроде 1С или Axapta. Есть скомпилированное ядро, если скриптовый язык, который может использовать как скомпилированные компоненты ядра, так и внешние компоненты, в том числе и скомпилированные.
Иными словами, интерпретатору отдается средний слой, тогда как верхний и нижний остается прерогативой компиляторов.
Такой подход как раз и позволяет легко оптимизировать что угодно, вынося это на нижний слой, без ущерба верхнему слою, который сразу компилируемый.

Одно непонятно: зачем вы верхний слой отдаете компилируемым языкам? Недостатки вижу (нельзя выполнять код, введенный пользователем), а преимущества- нет.
...
Рейтинг: 0 / 0
21.12.2017, 22:14
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574091
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
AlekseySQLНасколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).
Вы опоздали лет на 15. В играх для описания квестов и сценариев давно используется Python или Lua.
...
Рейтинг: 0 / 0
21.12.2017, 22:49
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574096
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
AlekseySQLДелал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?
Фраза построена непонятно. Предпочтительнее .. чем?

И не зависимо от ответа оба варианта будут никуда негодны. Микс С++/C# можно рассматривать
как миграцию легаси. Или допиливание дот-нета до поддержки специфичного железа.
...
Рейтинг: 0 / 0
21.12.2017, 22:53
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574107
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlekseySQL
Гость
maytonAlekseySQLДелал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?
Фраза построена непонятно. Предпочтительнее .. чем?

И не зависимо от ответа оба варианта будут никуда негодны. Микс С++/C# можно рассматривать
как миграцию легаси. Или допиливание дот-нета до поддержки специфичного железа.

Я подразумевал такой смысл: если в проекте также используется язык сценариев, который берет на себя "редковыполняемую" часть проекта, то для "долговыполняемой" части нужно использовать более быстрый язык программирования. Поэтому связка python & C++ более разумна, чем связка python & С#.

Да, и основное преимущество С#, как языка с более простым синтаксисом теряется, если там где нужен простой синтаксис используется еще более простой язык (python). Другими словами, С# с точки зрения сложности представляет собой нечто среднее между python и С++, и при подобном разделении проекта на две части он становится неудачным решением для обеих частей.

p.s. Умею я холивары устраивать :)
...
Рейтинг: 0 / 0
21.12.2017, 23:13
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574113
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
AlekseySQLp.s. Умею я холивары устраивать :)
бред.
...
Рейтинг: 0 / 0
21.12.2017, 23:38
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574126
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
AlekseySQLptr128Проблема в том, что любое приложение должно иметь ядро, которое, в том числе, будет порождать процессы (нити) и управлять ими. И это ядро так же является высоконагруженной частью приложения, и, желательно, его сразу иметь на компилируемом языке.
Одно непонятно: зачем вы верхний слой отдаете компилируемым языкам? Недостатки вижу (нельзя выполнять код, введенный пользователем), а преимущества- нет.
Потому что ядро, порождающее процессы и управляющее ими должно быть максимально быстрым. Делать его на интерпретаторе сродни тому, что делать ядро операционной системы на интерпретаторе. Ведь именно ядро будет обеспечивать для среднего слоя весь многопользовательский и мультизадачный сервис.

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

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

Собственно говоря, ядро будет выступать в качестве сервера приложений для толстого клиента или для веб-сервера. Но с расширенными возможностями, имея возможность самому порождать процессы по различным событиям или по расписанию.
...
Рейтинг: 0 / 0
22.12.2017, 00:39
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574155
Фотография CEMb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CEMb
Участник
Dimitry SibiryakovТы уверен, что не наоборот?..+1
maytonВы опоздали лет на 15. В играх для описания квестов и сценариев давно используется Python или Lua.+1, выносить как-то всю игровую логику на флагах или чем-то ещё в ядерную игровую механику - это мозгоубийство. А вот скриптовые языки поверх движка с этим справляются легко.
...
Рейтинг: 0 / 0
22.12.2017, 05:36
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574210
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Единственное, что интегрируется абсолютно со всем - это С.

Из С++ можно наружу отдать С-интерфейсы, а из Сшарп - нет.

Потому Сшарп здесь совсем не в тему. Интероперабельность только через ОЛЕ-прослойку, а она не везде "лезет".

Делать пользовательскую логику на скриптовых языках придумали очень давно.
...
Рейтинг: 0 / 0
22.12.2017, 09:23
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574235
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlekseySQL
Гость
ptr128Потому что ядро, порождающее процессы и управляющее ими должно быть максимально быстрым.

Почему вы считаете, что процессы должны порождаться и управляться в самом верху программного стека? Я думаю процессы должны создаваться и управляться по мере необходимости, т.е. в низовом коде. Иначе поломается инкапсуляция, и программа превратится в код- лапшу.
...
Рейтинг: 0 / 0
22.12.2017, 09:50
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574245
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
SiemarglЕдинственное, что интегрируется абсолютно со всем - это С.

Из С++ можно наружу отдать С-интерфейсы, а из Сшарп - нет.

Потому Сшарп здесь совсем не в тему. Интероперабельность только через ОЛЕ-прослойку, а она не везде "лезет".

Делать пользовательскую логику на скриптовых языках придумали очень давно.
Отдать c-интерфейсы наружу можно и из c# - готовить нужно уметь
...
Рейтинг: 0 / 0
22.12.2017, 10:00
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574274
скрептописец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
скрептописец
Гость
у связки ".NET/С# + скриптовый язык" есть такое преимущество перед связкой "С++ + скриптовый язык":
скриптовый язык может быть скомпилирован в тот же CIL и далее JIT-ирован рантаймом дотнета в машинный код, то есть в итого скорость его исполнения будет такой же, как и у C#.

есть куча готовых реализаций таких скриптовых языков - IronPython, IronRuby и т.д.

если захочется "поскриптовать" на самом C# (или F#, C++/CLI, VB.NET, JScript.NET) - нет проблем: компиляторы - часть фреймворка, и можно встроить редактор скриптов (можно в простом текстбоксе) в свою программу - будет работать без всякой студии (вопрос отладки, конечно, отдельный), при этом интеграция скриптов с кодом на C# будет полной и беспрокладочной в обе стороны

при большом желании можно соорудить транслятор со своего уникального языка в один из поддерживаемых дотнетом (+ конвертер позиции в коде (строка, колонка) из дотнетовского сообщения об ошибке компиляции для правильной подсветки ошибочного места уже в коде вашего языка)
...
Рейтинг: 0 / 0
22.12.2017, 10:40
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574332
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
AlekseySQLptr128Потому что ядро, порождающее процессы и управляющее ими должно быть максимально быстрым.

Почему вы считаете, что процессы должны порождаться и управляться в самом верху программного стека? Я думаю процессы должны создаваться и управляться по мере необходимости, т.е. в низовом коде. Иначе поломается инкапсуляция, и программа превратится в код- лапшу.
С чего Вы взяли, что верх программного стека - это ядро системы? Стек растет снизу вверх, по крайней мере на Intel архитектуре, начиная с 8008. А структуру приложения я рисую сверху вниз, по порядку вызова. Потому что привык читать сверху вниз и справа налево, а не наоборот )
То есть, верхним уровнем я называю ядро, вызываемое из ОС, а нижним - библиотеки.
...
Рейтинг: 0 / 0
22.12.2017, 11:54
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574350
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
ptr128верхним уровнем я называю ядро
не удивляйтесь, что вас не понимают
ptr128Стек растет снизу вверх, по крайней мере на Intel архитектуре, начиная с 8008.
и здесь всё наоборот (push - декрементирует регистр указателя стека)
...
Рейтинг: 0 / 0
22.12.2017, 12:18
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574393
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
Изопропилptr128верхним уровнем я называю ядро
не удивляйтесь, что вас не понимают
Буду тогда избегать понятия верх и низ )

ptr128Стек растет снизу вверх, по крайней мере на Intel архитектуре, начиная с 8008.
и здесь всё наоборот (push - декрементирует регистр указателя стека)[/quot]
Декрементирует - это да. А вот снизу вверх или сверху вниз? )))
...
Рейтинг: 0 / 0
22.12.2017, 13:01
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574423
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
ptr128А вот снизу вверх или сверху вниз? )))
– А не пролечу ли я всю землю насквозь? Вот будет смешно! Вылезаю – а люди вниз головой! Как их там зовут?.. Антипатии, кажется… (с)
...
Рейтинг: 0 / 0
22.12.2017, 13:43
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574526
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
AlekseySQLНасколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).

Делал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?

Есть ли какая- то книжка, статья, блог, канал youtube... где о подобном скрещивании можно почитать подробненько?

Благодарю за обмен опытом!
Не понял к чему тут слово "сейчас", если это давно. Впрочем, не важно. Вполне себе традиционная схема - если есть большой хост - процесс и куча dll, с функциями которые могут быть вызваны из хоста напрямую, из меню или еще как. И есть каталог скриптов, которые хост может запускать. Скрипты обращаются к функциям реализованным в этих dll и к объектам предоставляемым хостом. Собственно в самих dll лежат ресурсоемкие операции к примеру компрессия или перекодирование или что-то с длинными вычислениями над большими объектами. Те же ГИС к примеру. Как отработать функцию - реализовано в dll, а что и в каком порядке и к каким файлам или объектам в хост - процессе применять - это пользователи самим себе в скриптах рисуют. Программа апгрейдится без изменения этих пользовательских каталогов и показывает к примеру менюшку со списком функций из этих скриптов или просто сами их имена или еще как. Ну и получается что пользователи наращивают свою кастомную логику под свои задачи ну или им под заказ разово делают такие скрипты.
...
Рейтинг: 0 / 0
22.12.2017, 15:59
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574529
Фотография ну я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ну я
Участник
AlekseySQLDimitry Sibiryakov, на 1с программировал примерно 13 лет... Но я не про многопользовательские СУБД, где скорость работы отдельного пользователя не важна (поэтому, кстати, в 1с нет и никогда не будет многопоточности).
Из учебных курсов 1С про многопоточность и фоновые задания:
http://курсы-по-1с.рф/articles/как-ускорить-1с-многопоточность/
...
Рейтинг: 0 / 0
22.12.2017, 16:05
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574595
AlekseySQL
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlekseySQL
Гость
ну яИз учебных курсов 1С про многопоточность и фоновые задания:
http://курсы-по-1с.рф/articles/как-ускорить-1с-многопоточность/

Так можно и через COM из управляющей 1с запустить несколько подчиненных сеансов 1с и разделить между ними задачу. Но будет ли это многопоточностью? Тут происходит тоже самое.
...
Рейтинг: 0 / 0
22.12.2017, 18:01
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574602
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
AlekseySQLНасколько я понял сейчас набирает силу идея реализации программной "обертки" на скриптовых языках (типа python), а реализация прикладной логики- на языках низкого уровня (типа С++).
С++ не является языком низкого уровня. Это обычный себе прикладной язык.
Низкий уровень - это C и/или ассемблер.

AlekseySQLДелал ли кто- нибудь такие проекты? Как впечатления? Логично предположить, что С++ в такой связке становится предпочтительнее С#?
При чем тут C# предпочтительнее C++? И то и то компилируемые языки.

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

Современная игрушка просто на старт иногда требует несколько минут, не говоря уже на перелинковку, без быстрого изменения кода в runtime там вообще никак.

AlekseySQLЕсть ли какая- то книжка, статья, блог, канал youtube... где о подобном скрещивании можно почитать подробненько?

Благодарю за обмен опытом!
да нет никакого сакрального знания там.

единственно что стоит почитать - это про то, что писать на чистом LUA скрипты это несколько моветон.
статья была на хабре, лень читать

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


есть и интерпретируемые субдиалекты С или C++, или и вовсе - техника нативной компиляции в runtime с динамической выгрузкой/подгрузкой .dll/.so
т.е. цель достичь секундной реакции на изменение в коде можно достичь не только интерпретатором, а и традиционными средствами.
преимущества - отладка в родной IDE, нет необходимости отправлять открытый (нетранслированный) код в релиз, и т.п.

хотя так обычно мало кто парится, да и геймдевдизайнеры предпочитают ламповый LUA или подобное этим вашим звездочкам и & закорюкам.


но опять же - это все нужно лишь там, где от F5 до запуска приложения проходит более 30 секунд. иначе - проще писать сразу в одном языке и не париться
...
Рейтинг: 0 / 0
22.12.2017, 18:29
| Ответить | Цитировать | Написать  
Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
    #39574644
Фотография ptr128
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ptr128
Участник
dbpatchС++ не является языком низкого уровня. Это обычный себе прикладной язык.

Несмотря на то, что потребление памяти у C++ больше, чем у C, а производительность несколько ниже, его вполне успешно используют в качестве языка низкого уровня. Например, на том же Arduino, вообще без операционной системы.
Так что не все так однозначно.
...
Рейтинг: 0 / 0
22.12.2017, 20:35
| Ответить | Цитировать | Написать  
25 сообщений из 184, страница 1 из 8
  1  все
Форумы / C++ [игнор отключен] [закрыт для гостей] / Какие плюсы в использовании скриптового языка как менеджера вызова прикладной логики?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]