function example{bruh = 4, bro = 3} return 4 + 3 end

Так разве можно?

Ну вроде быы

проверю ещё раз

Нельзя

Ага, это не то

Ты вообще что-то странное написал

Очень

--lua 5.3 function bruh(table_) return table_[1] end print( bruh{"hi"} )

Так и в 5.1 можно

function example{bruh = 4, bro = 3} return 4 + 3 end

Инициализировал и "вызвал" функцию одновременно ))

О, Снюс проснулся

Сам ты снюс.

Сам ты снюс.

Как изволишь себя называть?

О, Снюс проснулся

Когда освоишь луа и стек технологий на моём уровне — будешь искажать снуса куда захочешь.

Когда освоишь луа и стек технологий на моём уровне — будешь искажать снуса куда захочешь.

Ну нифига себе заявление

Даже на такие жертвы готов, чтобы мотивировать людей на обучение😂

Думаю что это ещё нескоро (если вообще), а будущий я переживёт.

Пооффтоплю чуть-чуть: Кто-нибудь в QEMU запускал нативную aarch64 видну 10? А то у меня что-то даже до установки не доходит, процесс QEMU только одно ядро процессора грузит и лого винды показывает, а дальше нини

Даже IO операции никакие не идут

Это очень интересный вопрос. Я бы ковырнул несколько ВМ.

Мне просто интересно стало, как одна моя программка себя чувствовать будет на винде под ARM

А малинку трогать жалко, у меня на ней веб сервер и ещё много чего крутится

Мне просто интересно стало, как одна моя программка себя чувствовать будет на винде под ARM

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

в обоих случаях того, чего ты хочшеь добиться: Если ты хочешь проверить запуск x86-вендопрограммы на arm'овинде, то ты в данном случае триггеришь двойную софтварную кросс-архитектурную трансляцию. Не говоря уже о том, что между слоями там ещё оверхед от обоих ОС. Это будет ОЧЕНЬ медленно. Если же ты хочешь проверить скоспилированную под ARM версию программы, то оно, хоть и не будет так медленно, всё равно не освобождает тебя от недостатков медленности софтварной кросс-архитектурной эмуляции на x86. Ну и, впринципе, в этом случае нет особых причин переживать за самочувствие программы, если ты в ней не использовать x86 ASM ;)

Не 86ой

У меня уже бинари есть от aarch64, я их кросскомпилером собрал, мне не столько производительность интересна, сколько работоспособность без внесений изменения в код

ну, как я уже намекнул, если не было использовано ничего платформозависимого, то если оно собралось, то должно работать (иначе это вина не твоя, а компилятора) :)

Ну это ясное дело, прожка-то без варнов собралась, но хочется убедиться в отсутствии крашей

ну, как вариант ты можешь попробовать запустить её под вайном на той своей малине (впрочем, зависит от того что именно за вайн туда запаковали смейнтейнеры)

по правильному там должен быть aarch64-вайн (надеюсь, там не попались упорки, запаковавшие виртуализацию x86 в коробку к нему)

А разве есть arm64 вайн либы?

Ну именно от 10ки

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

если ему "базовой" системы, которую предоставляет вайн не хватит, то печалька

Вообще хватит

впрочем, способ "поворовать либы с установленной венды" в случае вайна работает вот уже лет эдак 25 :)

Но я сомневаюсь в том, что есть вайновские библиотеки arm64

впрочем, способ "поворовать либы с установленной венды" в случае вайна работает вот уже лет эдак 25 :)

было бы ещё откуда воровать

https://wiki.winehq.org/ARM

впрочем, статья, видать, немного устарела

"Meanwhile we support these new ARM PEs for win8! "

Хм, ну судя по всему виндовые arm PEшки поддерживаются

там делается акцент на восьмёрочные времена, но в самом начале написано что по дефолту вайн запускает нативные arm-бинари

Надо будет попробовать, авось что выйдет

а вообще, на худой конец, можно в IRC сходить, на фринод, на канал вайна и там поспрашивать

Господа (и дамы), кто-нибудь на visual studio 2019 успешно lua подключал?

Господа (и дамы), кто-нибудь на visual studio 2019 успешно lua подключал?

Ды, в чём фигня?

Господа (и дамы), кто-нибудь на visual studio 2019 успешно lua подключал?

а можно с самого начала - вот есть пустой экран студии...

Тебе библиотеку или приложение?

я хочу и язык подключить, и интерпретатор 5.3

имею ввиду, чтобы студия могла луа-проекты билдить, и читать разметку

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

Но очень захотелось начать

Ну кароч, 1. Создаёшь новый проект (win32/консольный/с окошком, какой хочешь); 2. В папку с проектом — добавляешь директорию /lib, в неё пихаешь lua53.lib, или что у тебя там; 3. Туда же — создаёшь папку /include, добавляешь туда луёвые заголовки; 4. Залезаешь в свойства проекта (Project/Properties) 4.1 Там у C/C++ выставляешь Additional Include Directories натравленные на папку $(ProjectDir)/include; 4.2 У Linker выставляешь Additional Depencies с Lua51.lib; 4.3 Забыл ещё про Linker/General, там в Additional Library Directories выставляешь $(ProjectDir)/lib; 5. В main.c/cpp пишешь #include "lua/lua.h" #include "lua/lauxlib.h" void main() { ... инициализируем стейт, ... запускаем скрипт и т.д. ... по учебнику }

Уточнение: разрядность и платформа конечного приложения должны быть те же что и .lib-библиотека.

Спасибо, попробую

Но это ты запускаешь из-под C луа, как встраиваемый

Разметка самого луа при этом в редакторе скриптов будет?

И нет ли способа сборку С части оставить самой среде (настройками), а в vs поднять сразу lua проект (как в eclipse, например)?

Аааа, стоп, ты про редактор Lua кода в Visual Studio?

Ну, как бэ да =)

А Eclipse умеет сразу делать луа-приложение?

редактор кода + интерпретатор

угу

нативно билдит C, и запускает интерпретатор сразу с файлов на вход

Ничоси, там небось какие-то хаки. Кароч, ты запихиваешь луа-скрипт рядом с исполняемым файлом, и в сишке пишешь: "исполнить этот скрипт, который рядом с исполняемым файлом".

GetCWD в помощь.

😳😱😭

GetCWD в помощь.

А это что за зверь такой?

Это сишная функция "получить текущую рабочую директорию". Один из способов получения пути до скрипта рядом с исполняемым файлом. Хотя мб в argv[0] чот будет, сконкатенируешь с именем скрипта.

Тоже, кстати вопрос - eclipse редактирует относительные пути до папки проекта, т.е. пофигу откуда запускаться, рабочей будет папка, выставленная как source в настройках проекта

"Смерджить" сишку и луа тоже можно. Просто вставь в сишный код строку с луа-кодом, и load'ни )) Не забудь дописать package.path/cpath на луёвой стороне.

Но если мы делает "запусти этот файл" через С - думаю, такой фичи нет, пути только относительно рабочей папки С?

"Смерджить" сишку и луа тоже можно. Просто вставь в сишный код строку с луа-кодом, и load'ни )) Не забудь дописать package.path/cpath на луёвой стороне.

Это чудовищный костыль же =)

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

Ну и исходный код луа чуть сложнее добыть. Придётся открывать exeшник hex-редактором.

на вопросы безопасности и защиты исходного кода я пока кладу с прибором =)