Совершенно случайно (автор форкнул мой форк cl-pdf, а я пошёл посмотреть кто такой) обнаружил cl-uglify-js - библиотеку (Common Lisp) для "сжатия" кода на JavaScript. Я вообще давно уже мечтал о подобной либе для CL, ибо тянуть в проект на CL что-нибудь типа Google Closure Compiler совсем не хочется. Теперь же всё получается просто. Я протестировал эту библиотеку на своём основном проекте, в частности, на коде который генерирует cl-closure-template и обнаружил, что проект всё ещё работает (никаких изменений не выявленно), а код превратился в жуткое нечитабельное сжатое месиво - именно то, что нужно.
Вообще, ситуация с разработкой высоко-интерактивных веб-приложений на Common Lisp начинает казаться мне всё более и более симпатичной.
Кстати, cl-uglify-js является портом UglifyJS - аналогичной библиотеки для Node.js того же автора, которая на github имеет более 300 подписчиков, что внушает серьёзный оптимизм. Забавно, что в UglifyJS для разбора JavaScript используется порт parse-js - вот такая вот тесная интеграция JavaScript и Common Lisp.
Подписаться на:
Комментарии к сообщению (Atom)
так победим :)
ОтветитьУдалить@Rigidus
ОтветитьУдалитьУже победили, но пусть это будет наш секрет ;)
Для полного счастья нужен ещё аналог compass.
ОтветитьУдалить@Andrey
ОтветитьУдалитьА что есть compass?
cl-uglify-js это хорошо, но cl-closure-template может это делать прямо из паренскрипта: выключить *ps-print-pretty* (http://common-lisp.net/project/parenscript/reference.html#*ps-print-pretty*) и http://common-lisp.net/project/parenscript/reference.html#section-obfuscation
ОтветитьУдалить@Vladimir Sedach
ОтветитьУдалитьНу, у меня и рукописного кода на JavaScript много ;)
Кроме того, есть ньюанс (в его причинах не разбирался), что сейчас cl-closure-template генерит какой-то лишний JS-код (не нужный, ничего ни делающий, типа повторного объявления переменных), а библиотека типа cl-uglify-js должна (по идее) его убирать.
И вообще, мне так кажется более правильным, что одно решение используется для генерации кода, а другое для его обфускации. Но надо будет почитать документацию на parenscript, а то я её практически не читал.
Кстати, чем сделана дока на parenscript? А то могу на cl-sphinx (как в restas) перевести, может удобней будет ;)
"Кроме того, есть ньюанс (в его причинах не разбирался), что сейчас cl-closure-template генерит какой-то лишний JS-код (не нужный, ничего ни делающий, типа повторного объявления переменных), а библиотека типа cl-uglify-js должна (по идее) его убирать."
ОтветитьУдалитьЕсли это делает паренскрипт, то можно считать багом и пожаловатся мне.
"И вообще, мне так кажется более правильным, что одно решение используется для генерации кода, а другое для его обфускации."
Одно важное средство паренскриптовской обфускации это то что одни и те же символы переименуются одинаково при каждом вызове компилятора, так что возможно генерировать обфускованный код динамически и совмещать его с раннее генерированным кодом.
Помимо паренскрипт может в теории делать обфускацию по круче чем простые обфускаторы тк понимает области видимости (в принципе можно делать злые вещи типа обратного альфа переименования - те переименовать всё что можно под одно имя).
Но если смотреть на вещи объективно, паренскрипт сам по себе уже является обфускатором ни в чём не виновного лисп кода.
"Кстати, чем сделана дока на parenscript? А то могу на cl-sphinx (как в restas) перевести, может удобней будет ;)"
Как проект который должен продвигать веб технологии, я считаю что все паренскриптовские доки должны быть написанны на HTML вручную.
Compass это такой компилятор из SCSS в CSS. А SCSS это расширение CSS, с переменными, выражениями, миксинами, и пр.
ОтветитьУдалитьhttp://compass-style.org/
Андрей, это cab с ЛОР-а. Вы могли бы глянуть тут - http://b-al-u.livejournal.com/71771.html Интересна ваша реакция.
ОтветитьУдалить@Balu
ОтветитьУдалитьСтатья, в общем, понравилась, только заключительная часть не достаточно раскрыта, как мне представляется. Кроме того - не понравилась ссылка на http://lisp.ru/ ))