Общий lisp: переносимость

Ответ 1

** ПРИМЕЧАНИЕ. Извините, если я укажу очевидное в этом сообщении, я не уверен, что вы знакомы с Common Lisp **

Выполняется с sds:

Кажется, что у вас есть немного жизни, когда вы запускаете андроид, но доступная производительность остается видимой. Очень маловероятно, что мы увидим игры lisp в магазине iphone, если они не скомпилируются на другом языке, где компилятор недоступен во время выполнения (см. Nu или для проприетарного варианта см. mocl, в котором есть способы решения этой проблемы)

Переносимость - во всех реализациях

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

Переносимость - через платформы

Обязательно проверьте ход выполнения предпочтительной реализации на каждой платформе, могут быть тонкие ошибки. Для меня я использую SBCL, и под Windows только 32bit полностью поддерживается, в то время как 64 еще находится в разработке.

Упаковка

У этого есть несколько хороших сроков для вас, так как некоторая информация о упаковке приложений Clozure для Apple Mac Store была опубликована сегодня на openmcl-devel. У меня еще не было хорошего чтения, но поток может предоставить дополнительную информацию.

Zach Beane также сделал buildapp для SBCL

У пользователей lispbuilder также есть некоторая информация о создании автономных исполняемых файлов.

Инструменты

cl-opengl - очень хорошая оболочка для opengl. Он поддерживает как старые, так и современные стили opengl, и поэтому я нахожу области, которые пытаются ограничить абстракции более высокого уровня (я лично избегаю cl-opengl gl-массивов). У вас есть чтение источника, хотя, как там есть некоторые замечательные вещи, особенно когда вы начинаете писать больше кода cffi. {cl-opengl все еще разрабатывается и доступен через quicklisp - я использовал его под linux и windows с радостью}

lispbuilder-sdl очень круто, но снова вы можете найти желание взять под контроль некоторые области. Например, макрос sdl: with-events велик, но он контролирует ваш основной цикл и обработку пошагового шага. Это может отлично сработать для вас, но если не бойтесь копаться и писать что-то лучше, чтобы заменить эти части!

Также lispbuilder предоставляет ряд библиотек, поэтому перед их использованием проверьте, есть ли более свежий эквивалент в quicklisp. Например, lispbuilder имеет lispbuilder-opengl. Не используйте это, придерживайтесь cl-opengl. Снова lispbuilder имеет lispbuilder-regex, хотя, вероятно, гораздо лучше использовать CL-PPCRE.

Я, вероятно, не рекомендовал бы использовать его как есть, но я потратил немного времени на то, чтобы избавиться от всех lispbuilder-sdl, которые не относились к современным играм opengl (так что никакие программные поверхности sdl и т.д.). Я не думаю, что люди должны использовать это, но это может дать вам некоторые идеи! {lispbuilder не находится в тяжелом развитии, но доступен через quicklisp - я использовал его под linux и windows с радостью}

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

Вышеупомянутое потребует использования SLIME или SLIMV, что означает использование Vim или Emacs. SLIME действительно стоит вашего времени, так что смотрите!

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

Посмотрите вперед, чтобы увидеть игру!

Ответ 2

Портативность

Вы должны различать переносимость между платформами (например, будет ли ваша программа разработана под Clozure на Windows работать в Linux?) и во всех реализациях (например, будет ли ваша программа Clozure работать под SBCL?)

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

Практически, вам нужно изучить, насколько хорошо Clozure работает на интересующих вас платформах и поддерживает ли CFFI Clozure на этих платформах. Эти вопросы лучше всего задавать разработчикам, а не здесь.

Installability

Все реализации CL делают "доставку продукта" каким-то образом, например, создавая автономные исполняемые файлы, которые затем можно упаковывать и распространять.

Ответ 3

Я смогу легко перенести его на другие платформы (linux/iPhone (возможно)/android) позже?

Ну, это во многом зависит от выбранных вами библиотек.

У меня вообще нет опыта разработки Android или iOS, но сейчас я разрабатываю небольшой проект в Common Lisp, который использует lispbuilder-sdl, cl-opengl, quicklisp и т.д., и не было проблемы портирования между SBCL на Linux до Clozure-CL на Windows.

Кроме того, существует хотя бы одна перспективная мобильная реализация Common Lisp: https://wukix.com/mocl

Итак, я думаю, что у вас не будет проблем с переносом кода, просто убедитесь, что все библиотеки, используемые в вашем приложении, имеют соответствующую поддержку на каждой платформе и реализацию Lisp.

Является ли Lisp "подходящим" для устанавливаемых программ?

Большинство Lisps имеют возможность создавать автономные исполняемые файлы со встроенными библиотеками. С другой стороны, если ваш проект станет достаточно большим, вам придется писать специфичные для платформы установщики, не зависящие от возможных Lisp связанных проблем. И я сомневаюсь, что Lisp -связанная часть оказывается самой сложной. Также проверьте это сообщение: Lisp Исполняемый файл и рассмотрите идею распространения Lisp изображений во время выполнения вместо автономных исполняемых файлов.

Ответ 4

Для использования Common Lisp в качестве игрового времени выполнения есть отличный ответ.

Я просто хочу упомянуть, что игры в PlayStation 2 Jak и Daxter: предшественник Legacy и Crash Bondicoot разрабатываются с использованием Common Lisp несколькими способами.

У них была их среда разработки в Commmon Lisp и сделал игровой язык GOAL (позже GOOL), это был язык высокого уровня с монтажной вставкой (как C __asm__). Таким образом, продукт не имеет ничего общего с его средой разработки, когда был скомпилирован конечный продукт.

Они ориентированы только на одну платформу (PS2), но я думаю, что можно было бы создать языковые конструкции, чтобы вы могли оптимизировать для нескольких платформ, используя почти одинаковый метод. Создание игрового языка позволит абстрагировать фактические различия в оборудовании и библиотеке и снизить сложность компилятора, чем пытаться скомпилировать Common Lisp, например. Далвик прямо. компилятору действительно не нужно заканчивать как объектный код. Он может скомпилировать C/Java/Objective C.

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