Я остановился на контейнерах. Lodash подойдёт в качестве образца? Или родные CL-ные лучше?

В прекрасной программе Lotus Notes (да и в обычном sudo) есть такая киллер-фича: если со времени прошлой проверки, что я - это я, прошло достаточно времени, то программка в произвольном месте делает

await а-ну-ка-введи-логин-снова()

Теперь представим себе ситуацию. Я делаю форум, в котором хочу такую фичу. Допустим, каждые 60 минут сессия пользователя закрывается. И вот, он сидел, писал комментарий, нажал «отправить». Ушёл POST-запрос на сервер. Возможно, это ajax, а может быть, подразумевается redirect после выполнения записи в БД постов. Но оказывается, что пора проверить логин. По сути это будет означать последовательность запросов - нужно сначала отложить в карман отправленный пользователем комментарий, затем заставить его ввести пароль, и затем отправить текст пользователя повторно.

Вопрос такой: можно ли сделать это без большого усложнения клиента?

(я чайник в веб-технологиях, может быть, спрашиваю полный бред).

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

И желательно, чтобы пополнять его было не крайне сложной задачей, а постижимой простым ламером.

Хочу сделать небольшое и легконагруженное приложение - редактор словарей терминов. Есть список слов, можно искать слово. У слова есть карточка, которая своя для каждого пользователя, но можно смотреть чужие карточки. Карточка в формате markdown или что-то около того.

Клиента буду делать на vue.js, а сервер хочу на node.js . Да, меня уже отговаривали использовать node.js на стороне сервера. Но вдруг для такого простого проекта прокатит? В принципе, я готов всю тяжесть написать на pl/pgSQL, а на нодке - только тончайший интерфейс и собственно веб сервер. Соответственно, вопрос - как там с утечками памяти и прочими такими вот ужасами?

Т.е. вопрос состоит не в удобстве и не в производительности, а в качестве с т.з. надёжности.

Перемещено tailgunner из development

Хочу вот освоить веб, дабы зарабатывать на хлеб насущный. До этого зарабатывал на Delphi + разные SQL ну и баловался лиспом. Но всё это сейчас кормит довольно плохо.

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

Путём анализа stateofjs.com, rabota.yandex.ru и опроса населения получается как-то так:

bootstrap 3 + react + expressjs + webpack + nodejs + webstorm + babel + mysql

Есть ещё какие-то компиляторы для CCS, но до этого я пока не докопался даже.

Вёрсткой заниматься не собираюсь, только программирование. Хотя кто знает, может и до этого дойду когда-нибудь.

Js мне вообще не нравится, но для клиента он неизбежен. Хочется учить как можно меньше, поскольку возраст уже не пионерский. А раз можно использовать один и тот же язык для сервера, клиента и сборки - это вроде как на первый взгляд выглядит хорошим вариантом.

Куда с этим багажом лезть - я пока не понял, может быть буду пытаться найти частных заказчиков.

Правильно ли выбрал направления развития? А то я тут начитался, что всё это хипстота и что PHP+html+jquery - это наше всё.

И вообще, насколько веб сегодня актуален, насколько актуальна работа по частным заказам? Я просто зашёл на сайты двух веб-студий в своём городе, увидел главную страницу и мне подумалось, что сделать хуже мне не удастся при всех стараниях. Т.е. с точки зрения конкурентоспособности на этом рынке бояться нечего. А вот с точки зрения осмысленности участия в этом рынке - я пока не понял.

antares0, я не понял, почему бага про треды, которую я недавно упоминал, оказалась исправлена в 1.4.4? С 2015 года до неё никому не было дела и вдруг... Это случайное совпадение или всё же моё фэ, высказанное во многих местах, в т.ч. и на sbcl-devel оказалась живительным факапом? Я смотрю, новый релиз SBCL почти полностью посвящён исправлению багов :) Наконец-то они занялись делом. Если так дело пойдёт, года через два можно будет рассматривать SBCL как что-то годное :)

Жду твою новую теорию о том, что я странный парень и как у меня не складывается с людьми. Видишь, иногда мои факапы работают, несмотря на мои странности :) Видимо, спасибо ждать не стоит, поэтому придётся мне самому себя похвалить :)

Я видел https://github.com/benweet/stackedit, но это нода. Его можно установить оффлайн. Но ведь есть и дедовский способ делать офлайн - сохранить страницу на свой диск и запускать её локально. Вопрос такой: может ли в прироед быть просто страничка, в которой я могу редактировать Markdown и видеть превью, которая исполняется полностью на стороне клиента. ЧТобы я мог сохранить эту страничку на свой диск и маркдаун продолжал показываться. Есть даже библиотека ShowDown, которая рендерит маркдаун.

<a href=«trarara.html»>А теперь переключим раскладку. И опять переключим</a>

Кто как решает вот эту проблему?

Решил попробовать слезть с CL и перейти на другой язык. Рассматриваю варианты. Например, посмотрел на Оберон. Он хорош тем, что там почти ничего нет, но этим же он и плох.

Интересен Gambit - трансляция в Си позволяет (попытаться) отлаживать неработающие программы обычным отладчиком для Си. Но есть и интерпретатор. По показателям github (звёзды, форки и пр) - примерно равен ClozureCL и вдвое меньше SBCL.

Но потом посмотрел трекер. Да, Gambit тоже бывает, что падает. А вот golang вроде должен быть понадёжнее. Единственное, мне опять же не нравится отсутствие пошагового отладчика. Похоже, мои неудавшиеся эксперименты на ClozureCL - это более продвинутая технология, чем то, что есть в golang. Но в golang оно зато (вроде бы) работает.

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

Ну и далее, Схема - всё же маргинальщина, а на голанге, если что, можно и на хлеб заработать.

А мне, представьте себе, ещё не надоело засорять ЛОР своими ненужными улучшениями для лиспа.

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

Большое преимущество - можно брать готовую функцию и инструментировать её для ходьбы без перекомпиляции. Этим он кардинально отличается в лучшую сторону от LW, который переопределяет функцию при установке брекпойнта. Недостаток, правда, в том, что шаги слишком редкие - как в SBCL. Чтобы шаги стали чаще, нужно допиливать ещё. И без перекомпиляции под другую политику оптимизации (при данном подходе) не обойтись. Хотя я вот не знаю, нужно ли допиливать или нет. В 80-строчной функции появилось 16 точек шагания. Вроде это мало, но по сравнению с trace, когда точка шагания всего одна - уже и не так мало. Может быть, если их подсветить, будет достаточно. Мозг-то никто не отнимает, можно им доработать, где шагов не хватает.

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

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

https://www.youtube.com/watch?v=1f4QRS0d8NU&t=6s

Выложил очередной релиз Яра, «разочаровывающий». Дело идёт к заморозке проекта, работаю над ним до 1 февраля, а потом хлеб насущный буду зарабатывать. Найти спонсора за два года не удалось. Видимо, дело в недостаточной вере в успех, т.е. в отсутствии ощущения зрелости проекта, при которой можно называть сроки и нести за них ответственность.

Из последних конвульсий: теперь clcon поддерживает также CCL, а не только SBCL. Ну и Яр, соответственно, собирается и запускается под CCL под Linux и Windows. Зато я что-то сломал и образ SBCL под линуксом не сохраняется. С точностью до системы знаю. Впрочем, не суть важно.

Правы были те, кто говорил, что не нужно пытаться менять CL. Он хорошо защищён от изменений частоколом из грабель: если делаешь не совсем общепринятые вещи даже в рамках стандарта, например, свою readtable, проблем огребёшь по полной, и я их огрёб, и на них был истрачен ценный трудовой ресурс. А без всяких улучшений он слишком скучен для меня.

Если вдруг кому интересно, за последние месяцы немного поразбирался в SBCL, и пришёл к тому выводу, что можно наляпать много нового и интересного, но поскольку там всё внутри черт-те в каком состоянии, причём хронически, то по сути дела работать ничего не будет. Красивую показуху сделать можно. Я сделал черновик иммутабельных хеш-таблиц и струтур с рассуждениями о типах в них, а также сильно улучшил пошаговую отладку. После этого я пообщался с одним из разработчиков и, оказывается, они тоже мечтают про отладчик а-ля Visual Basic, но сделать его быстро не могут, т.к. примитивы, на которых он должен быть построен, низкокачественные. Сейчас, судя по коммитам, они их начали исправлять. Дай Бог, чтобы у них получилось. Однако я не вижу причины, по которой не может существовать инструментирующий отладчик для CL. Более того, он уже существует и называется lispdebug-0.92 - жаль, что лицензия подкачала.

Также отчасти разобрался в работе вывода типов. Там есть два механизма - собственно type inference и constraint propagation. Если о первом я имею кое-какое представление, то второй - вообще тёмный лес. Потому и захотел отладчик, чтобы лазить туда не с голыми руками, а вооружившись удобным инструментом. Но - не склалось у меня с SBCL.

В итоге теперь у Яра нет отладчика и не на что опереться в плане вывода типов. Может быть, попробую сделать «Яр на базе Typescript», хотя при отсутствии материальных ресурсов думается на эту тему тяжело - ясно, что создать серьёзный ЯП с инфраструктурой - это достаточно трудоёмко. Более трудоёмко, чем казалось сначала по факту написание за две недели транслятора с 1С 7.7 в CL.

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

Просто по темпам развития понятно, что они меня съедят в любом случае. Ну и честно говоря, я ожидал, что меня будут смешивать с говном на форумах за идею русскоязычного языка программирования. Но то, что к этой идее окажутся холодны Росатом, ФПИ, Касперский, 1С и фонд «Русский Мир» - к этому я был морально несколько не готов. Такое чувство, что никто не догоняет, что за вытеснением из обихода «неэффективного» русского языка может произойти и вытеснение с территории и самого населения, говорящего на «неэффективном» языке. Вроде как и Казахстан уже на латиницу переходит, и на Украине черт-те что. Нет, Россия спит. Впрочем, в одном месте мне указали на соседний вход и сказали, что нужно обязательно писать заявку на грант, но почему-то моральных сил пока нет. Может быть, через некоторое время появятся.

Попробую за оставшиеся 10 дней сделать для CCL инструментирующий пошаговый отладчик - тредов не будет, уж извините.

Не совсем portable, но заметно расширяет возможности для SBCL и CCL и приводит их к общему знаменателю. Для остальных реализаций возможно не более одного «совета» на функцию и реализация не завязана на родные возможности реализаций, а просто перешибает defun.

https://bitbucket.org/budden/cl-advice

В CCL не просто можно вызвать предыдущую функцию (с помощью (:do-it)), но и подменить ей аргументы.

В SBCL можно найти определения самой функции и её «советов» с помощью SWANK.

Говоря холиварно, это позор, что в EMACS и в питоне декораторы есть, а в CL - нет. Уж лет 20, как пора было это исправить и вот я сделал к этому шаг наконец-то.

На самом деле код ещё довольно сырой - для CCL я написал его сегодня и не факт, что завтра что-то не всплывёт. Для SBCL уже несколько месяцев пользуюсь - вроде всё нормально.

http://core.tcl.tk/tk/tktview?name=52e9b0f52c - после 8.6.6 %K для кириллицы сломан (когда точно - не помню)

http://core.tcl.tk/tk/info/62f1343ad2 - Tk textbox not working with «Bengali» set as keyboard input language

http://core.tcl.tk/tk/tktview/6c0d7aec6713ab6a7c3e12dff7f26bff4679bc9d - не помню, в чём именно проблема, но она плохая и приводит к тому, что иногда буквы путаются (особенно, если нажимать на кнопки достаточно быстро). Эта бага исправлена уже.

Если предположить, что CL имеет смысл и создание новой IDE для него имеет смысл, перевод моей IDE с tcl/tk на atom имеет ли смысл? В нынешнем состоянии atom-slime выглядит так

Уж не знаю, сюда ли пишу, но я придумал обратимый транслит. Наверное, я не первый - было что-то даже на Хабре. Но тем не менее. Я старался. Вот что есть на текущий момент.

Не только кириллица, но и смешанный текст из кириллицы и латиницы можно обратимо преобразовать.

В чащах юга жил бы цитрус? 
Да, но фальшивый экземпляр!
Hello!
===> 
V chashhakh yuga zhil byy citrus? 
Da, no falqshivyyyi ehkzemplyar!
jHjejljljo!

Извините, обратное преобразование пока не сделал.

Более хороший степпер для SBCL, хотя ещё пахать - не перепахать

https://www.youtube.com/watch?v=UlXn-ujS500

А вот моя «база знаний» по начинке SBCL

Вот прочитал, что они существуют и в ext3 вроде как присутствуют.

Вопрос такой: можно ли в реальности использовать их конечному пользователю для хранения кодировки.

Например, в EMACS можно написать кодировку в первой строке. Но далеко не все редакторы это понимают, и нужно менять сам файл, если кодировка меняется.

А можно ли сделать так, чтобы кодировка хранилась в расширенных атрибутах файла, и чтобы я мог в следующих случаях сразу знать кодировку файла:

- файл открыт редактором (допустим, leafpad-ом) - файл получен по эл. почте в виде вложения - файл загружен через браузер - файл расшарен через самбу - файл перенесён из другой системы на флешке

Насколько я понял, и ext3, и ntfs в принципе позволяют хранить кодировку в extended attributes, вопрос лишь в том, чтобы всё это заработало как система.

Вот я и хочу понять, чего для работоспособности этой системы сейчас не хватает.

Предыдущая серия фильма была здесь:

Исправить SBCL - добровольцы есть?

Теперь вот: http://lisper.ru/forum/thread/1361#comment-12370

https://github.com/budden/sbclt/commit/ba9ffd6d45441feed345b3a4dcfc1263daee94e9

Коротко говоря, ввёл в SBCL типы (mutable 1) (мутабельный) и (mutable 0) (иммутабельный). character, number иммутабельны всегда. Хеш-таблица иммутабельна, если она заморожена вызовом freeze-object. Если объект объявлен с типом (mutable 0), то (setf (gethash)) вызовет warning при компиляции, и в рантайме этот код упадёт.

Чего здесь сильно не хватает - это передачи выведенной информации об immutable в другое место. Например, пока нельзя объявить, что параметр у функции immutable, чтобы компилятор ругался при попытке передать в него mutable объект. На эту цель был ранее сделан заход, но полностью работающего решения не удалось получить. Видимо, займусь этим завтра и далее.

Также нужно, чтобы вывод типов понимал, что объект, который сейчас immutable, будет и впредь immutable, но про прошлое ничего сказать нельзя (т.е. в прошлом он мог оказаться и mutable). Я не настолько понимаю вывод типов в SBCL, чтобы это сделать. Нужно сидеть и разбираться - это нелегко.

И ещё - я пытаюсь фиксировать то, что узнаю по мере изучения SBCL. вот тут

https://budden73.livejournal.com/27328.html

Цена полного решения - 20 тыр.

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

Я хочу следующие исправления/улучшения в SBCL:

Некорректная работа вывода типов

(defparameter *g* (cons 1 2))
(defun g () (setf (car *g*) 'a))

(defun f (x)
  (when (typep x '(cons fixnum))
    (g)
    (if (typep x '(cons fixnum))
      "Still cons fixnum!"
      "Not cons fixnum")))
(f *g*)

Нужно внести в язык и в реализацию понятие о настоящем и ненастоящем типе и сделать так, чтобы вывод типов не использовал ненастоящие типы (или использовал их настоящую часть, в данном случае cons). При этом будет установлено, что defstruct-ы и deftype всегда будут переопределяться только вместе с unintern того символа, который их именует, за счёт этого настоящих типов станет гораздо больше.

Декларация const Нужно её как-то воплотить и использовать в системе типов. Соответственно, если объект const, то его можно передавать только в функцию, которая принимает const. Для структур, массивов и консов const распространяется только на первый уровнь ссылок (или рекурсивно? я не знаю, как надо сделать). Для классов CLOS - не нужно ничего делать, они меня не интересуют и я ими не пользуюсь.

Запрет неявного сужения типов Добавить новое качество оптимизации (к speed, debug и т.п.). Если это качество включено, то присваивание месту, декларированному как integer, типа number порождает warning или compilation error.

Мне нужен чистый форк и внесение изменений в реализацию, а не просто патчи. Патчами можно сделать далеко не всё. Примут его или нет, как его поддерживать потом - это всё на данном этапе неважно. Нужно решить техническую задачу.

Если найдутся добровольцы, то я только за. Напоминаю, что анонимусы у меня в игноре, так что анонимусы могут в тему вообще ничего не писать :) И денег хрен заплачу :)