Константин, насколько я представляю себе Электрон, это и есть - движок Хрома, позволяющий обвесить себя добром, написанным в Javascript (в т.ч. во всяких там реактах) без необходимости лезть в "кресты" и перекомпиляцию. С ним при некотором желании должны справиться ваши же прогеры.
Пересобирать Хром имеет смысл только в том случае, если вы хотите в нем что-то изменить и готовы это изменение поддерживать и далее. У вас такой задачи нет.
Константин, вы же все равно не сможете поддерживать свою ветку, пересобирая браузер после каждого обновления Хрома и предлагая клиентам обновления.
Может, рассмотреть вариант переноса проекта на Electron? Для React-а это вполне естественная среда.
Поскольку вы не специалист и у вас нет команды, готовой разрабатывать и поддерживать - скорее всего, вам не нужен свой браузер на основе Хромиума. Достаточно использовать WebKit, например, с которым крестовик, знакомый с Qt, вполне может справиться.
Просто обобщите задачу и не навязывайте столь амбициозное решение, если не уверены в его необходимости.
Мечта. Если работа не завязана на Windows-only программы - поставить Линукс, перетерпеть месяц криков о том, что ничего не работает, потому что ярлык не того цвета, и забыть про этот офис, потому что там просто все работает, и сломать теткам ничего не удается.
Реальность. Просто отбери у теток права администратора и запрети запуск чего бы то ни было с флешек.
Сергей Горностаев, вот вы смеетесь, а смогли бы назвать другую CMS магазина, у которой запись о заказе в БД - это 75 столбцов только в основной таблице, не считая вспомогательных?
Я лично аналогов не знаю... к счастью...
Camaro67, при проектировании оплаты задумываться над вариантами развития событий и гарантией того, чтобы пользователь получил то, за что заплатил - это хороший шаблон.
А вот делать только то, что встретилось в документации, а потом разгребать реальные юзкейсы - не очень.
Camaro67, кто из нас не видит этой разницы?
Половина способов оплаты на Робокассе происходят НЕ на сайте Робокассы. Какой бы SuccessURL вы ни выставили - клиент по нему тупо не попадет, поскольку с сайта Робокассы он уже ушел, и возвращаться ему туда незачем.
В той же документации, собственно, и написано, что совершать какие бы то ни было действия нужно в обработчике ResultURL, а SuccessURL - это так, для декора.
Camaro67, не ткнете меня, скудоумного, в то место документации, где рассказывается, как клиент вообще попадет на сайт Робокассы после успешной оплаты, скажем, через Евросеть? А то я последний раз читал документацию, когда подключал Робокассу, это было лет восемь назад...
Второй цикл стоит исправить так, чтобы в нем использовалась переменная цикла.
А в первом стоит задуматься - то ли i = 0, то ли i <= countstring. Вряд ли то и другое одновременно.
Eldrich, а я, кстати, погорячился насчет подсвечников. За вызов в цикле функции, единственное назначение которой - перемножение аргументов, вас бы просто выкинули за порог.
Еще раз: не верю, что у вас какие-то уникальные данные считаются для каждой ячейки. Ищите, где считается одно и то же, и сохраняйте результат. Самое лучшее ускорение расчетов - это не считать вообще.
Как минимум, там, где заполняются эти вектора, сразу посчитать произведение x * x, x * y и y * y. Чтобы потом не делать это в каждом цикле.
ksnk, даже спорить не буду. Я отвечал, как оптимальнее решать то ТЗ, которое выложил ТС.
То, что оно весьма далеко от реальности - это уже его проблемы ;)
Там точно в математической части не считаются одни и те же данные? Может, их можно кэшировать?
inp[this.thread.y][i] используется трижды. Почему не присвоить его значение локальной переменной?
Может быть, конечно, JS сам кеширует такие обращения. Но в С за подобный код избили бы подсвечниками.
Anton Mashletov, вы меня не поняли. Я верю, что в WSL от линукса подгружается не так много, линукс вообще штука гибкая. Но вот то, что для запуска этого немногого используется аж целая Десяточка - это технически даже более чудовищно, чем мессенджер на Electron.
Удачи!