не уверен, что буду публиковать статью по сути задачи, т.к она связана с глубинными темами Иудаизма и иудейской мистики - не релевантная для Хабра тема.
Но кажется, что здесь всё на пальцах можно объяснить по сути ускорения алгоритма, что даже скучно статью про это делать:
1 - некоторые пути на заведомо фиксированном графе не эффективны, их можно исключить на старте.
2 - если нужно пройти 8 шагов, то каждый шаг - это как возведение в степень по количеству вариантов, а метод MITM (Meet In The Middle) идет с двух концов до середины, и в середине пересечение двух сетов находит - это позволяет отсечь 4 степени вариантов.
Получается, что в 500 раз - это ускорился поиск на моих цепочках. При удлинении цепочек ускорение будет расти.
У меня ускорял 500 раз. Сложный алгоритм последовательностей на графах. Сам я выжал всё, что знаю - минимум O, аллокаций, быстрые хеши, предельно сжатые в примитивы типы.
Но пришел Опус и в коде учел особенности графа, добавил MITM (Meet In The Middle).
То, что считалось неделю - посчиталось за 15 минут
Хорошо. Мне кажется, что быть в тех категориях людей, которые эффективно используют токены - это большой плюс. Мне видится, что хорошо всем людям войти в эту категорию - я за этот хайп.
Если, гипотетически, все люди войдут в эту категорию, то верно ли я понимаю, что ваш посыл рефрейминга нарративов будет адресован никому, по принципу “для вас и ваших знакомых наверное не меняется”?
Всегда какие-то прфоессии устаревали - что именно вы предлагаете и кому именно? Например, что можно преложить разработчику, который покупает несоклько Max подписок?
Возможно дело не в названии. Мои знакомые попкупают не ИИ/AI, а вполне измеримые токены. Мне кажется, что им не важно как это называется.
На что это повлияет? Условно, я, покупаю токены Антропика и ОпенАИ - что меняется от того, что кто-то это как-то называет?
В чем пузырь? Я знаю людей, которые покупают две MAX подписки, потребляют токены - а токены работают как три отдела программистов. Пузырь - это скорее про инвестиции, но разработчиков много идут к ним - просто покупают токены, это не вложения, а покупка реальной выгоды. Так же корпоративные игроки - много покупают токенов и реализуют выгоду. Если их отданные деньги потеряются - разработчикам и компаниям будет всё равно т.к они купили токены и реализовали их. Вопрос “Что конкретно выиграет общество” открыт и ждет ответа. Пузырь был в скобках вопроса - чтобы сразу отвести с него фокус, сфокусироваться на главной части вопроса, и получить ответ на главную часть - зачем кому-то брать эти нарративы.
Вопрос: в чем отличии тех, кто торопится от тех, кто не торопится? Это прямое следствие первого вопроса. Куда торопятся те, кто никак не в лидерах?
Если, условно, “вы” окажетесь в лидерах, то тоже перестанете торопиться сменить нарративы? И кажется Apple участвуют через сотрудничество т.к упустили момент стать лидерами, там же MS. И да, видно, что MS пытается тоже захватить право управлять нарративами.
Когда большие игроки,которые пропустили гонку, пытаются управлять нарративами - это понятно. Но когда мелкие игроки таются управлять нарративами - это хочу понять с их слов, какая у них мотивация.
Спасибо за статью! Если я правильно понял, в статье происходит столкновение нарративов и столкновение возможностей эти нарративы создавать и менять. Возникло три вопроса, буду рад узнать ваше мнение:
Что конкретно выиграет общество, если массово перейдёт на ваш прагматичный нарратив (помимо снижения рисков потенциального финансового пузыря)?
Почему, по вашему мнению, новые сильные игроки на рынке (например, разработчики Qwen или GLM) не пытаются сломать этот хайп и сменить правила игры, а продолжают играть по устовшимся правилам?
Логичное продолжение второго вопроса. А если представить, что сообщество трезвомыслящих людей (или вы лично) оказалось бы в позиции, где оно задаёт тон и смыслы индустрии по праву реального лидерства в мире, - стали бы вы целенаправленно менять нарративы, которые играют на вас лично, или достаточно просто называть вещи своими именами и ждать, пока рынок сам скорректируется?
Кавычки - просто часть строки. В Ktav нет механизма квотирования ключей. “port” как ключ - это буквально пять символов, кавычки часть - имени. Именно это и произошло в вашем примере: “port” с кавычками внутри JSON стал ключом “port” с кавычками внутри Ktav.
Двоеточие - да, только :, других вариантов нет. Экранирование ключей (. : , { } [ ] \ \n \r) есть с 0.6.0.
По ошибке. Ваш service: abc писался верно, предупреждение - ложное. Заодно нашёл кое-что: бандл плейграунда не пересобирали после апдейта ядра до 0.6.3, сайт раздавал старый WASM. Починил и задеплоил, можно перепроверять на https://ktav-lang.github.io/. Спасибо!
Про JSON5-style кавычки - не подумали об этом на старте. Мне сейчас кажется даже странным, что упустили такое. Справедливо, действительно хочется опциональные кавычки. Не обещаю, но возможно сделаем в следующих версиях.
Добавить есть что - хорошо бы тесты добавть. Чужой код без тестов - как пыльный мешок с ножами. Вроде там что-то полезное, но трогать не хочется, а тем более нести.
Одинарные скобки делают красивый триминг отступов когда можно сохранить целостность данных (в обратном конвертировании они значат, что отступы не нужны). Двойные - сохраняют строку как есть. Такой была цель.
Это не пробел в спеке - она уже требует именно того, чего вам хочется. § 5.9.5(b) и § 5.9.7 прямо запрещают однострочную форму для строки с краевыми пробелами и обязывают многострочный блок ((…)) вместо неё.
Направление вы нащупали точно: ktav -> json у вас работает правильно, потому что там парсер, а он спеке следует. json -> ktav - это запись, и вот там баг: строка с пробелом по краям сейчас молча теряет байты вместо того, чтобы уйти в блок. Проверил на самом остром случае - строка “\ttrue”: вместо блока сейчас пишется однострочное field1:: true, а при обратном чтении ведущий таб пропадает вообще, значение схлопывается в чистое “true”. То есть это не просто некрасивая форма записи, а реальная потеря байта.
Этот же класс бага @chappihappymeal нашёл и прислал с PR, независимо от вас:
Я прогнал ваш случай на ветке этого PR отдельно - чинит и его: та же строка с ведущим табом уходит в ((…)) и возвращается обратно байт в байт. Фикс идёт в ближайший патч-релиз 0.6.3, ничего не ломает - плейграунд подтянет его следующим обновлением вендоренного WASM.
И раз тема всплыла - параллельно копится пачка для отдельного релиза 0.7. Там уже прилично набралось: и спеку, и все семь парсеров гонять волной ради одной мелкой правки слишком дорого, поэтому такие изменения собираем до критической массы, а не выкатываем по одному.
Это будет масштабной работой. Не уверен, что возмусь за это, но мне нравятся ваши слова. В любом случае, это будет либо ktavPlus - вторым форматом (как TS над JS), либо обвязкой.
Оригинальный ktav очень хочу сохранить в простом виде - мне он тоже нравится именно своей простотой.
Если вы готовы быть поставщиком идей (в случае, если возьмусь) - создайте issue (https://github.com/ktav-lang/spec/issues). Если в будущем возьмусь, то я отпишусь под ним.
Спасибо - точное и ценное замечание, круто, что вы сразу нашли реальуню вещь, которая стоит доработки!
Это не пробел в спеке - она уже требует именно того, чего вам хочется. § 5.9.5(b) и § 5.9.7 прямо запрещают однострочную форму для строки с краевыми пробелами и обязывают многострочный блок ((…)) вместо неё. Отдельные кавычки не нужны - механизм для этого случая в формате уже есть, просто writer его не соблюдает.
Направление вы нащупали точно: ktav -> json у вас работает правильно, потому что там парсер, а он спеке следует. json -> ktav - это запись, и вот там баг: строка с пробелом по краям сейчас молча теряет байты вместо того, чтобы уйти в блок.
Этот же баг на этой неделе нашёл и прислал с PR @chappihappymeal - независимо от вас, через код.
И раз тема всплыла - параллельно копится пачка для отдельного релиза 0.7. Там уже прилично набралось: и спеку, и все семь парсеров гонять волной ради одной мелкой правки слишком дорого, поэтому такие изменения собираем до критической массы
Очень ценные запросы, спасибо! И почти всё здесь я готов подписать.
Про валидацию соглашусь. В другом комментарии я предлагал ровно то, что вы отвергаете - взять JSON Schema и проверять ей уже разобранный конфиг. Но тогда проверка идёт по готовым данным, в которых уже не осталось привязки к строкам файла. Подсветить ошибку в редакторе нечем.
Про остальные четыре пункта скажу прямо: этого нет. Почему - мы этим просто не занимались и не планировали заниматься. Формат отвечает на вопрос, как выглядит файл, а окружения, include и merge - это уже про то, как конфигурация собирается из нескольких файлов. Другой слой.
JSON и TOML останавливаются там же. Вы сами это отмечаете - и ваш тезис именно в том, что между форматом и полноценным инструментом остаётся дыра. С этим спорить нечего, дыра есть.
Мне кажется правильным закрывать её не изменением формата, а отдельной необязательной спекой поверх него: include как соглашение над обычными Ktav-документами, семантика глубокого merge (включая удаление ключа, а не только замену), выбор окружения, соглашение о ссылках на внешние секреты. Тогда файл остаётся обычным Ktav для тех, кому обвязка не нужна.
Спасибо, именно так. Это было в моей слепой зоне, “глаз замылился” и знаний не хватило.
Выше ответил - https://habr.com/ru/articles/1079940/#comment_30410846
Прошу прощения, если не ясно выражаюсь. Но кажется, я выжал сейчас предел объяснений, понятнее некуда, если “в двух словах” - Было N^8, стало 2N^4
Т.е прошлый алгоритм я выжал, да, но Опус сделал алгоритм другим
upd: если желаете, могу привести примеры кода в упрощенном виде, когда N^8 превращается в 2N^4
не уверен, что буду публиковать статью по сути задачи, т.к она связана с глубинными темами Иудаизма и иудейской мистики - не релевантная для Хабра тема.
Но кажется, что здесь всё на пальцах можно объяснить по сути ускорения алгоритма, что даже скучно статью про это делать:
1 - некоторые пути на заведомо фиксированном графе не эффективны, их можно исключить на старте.
2 - если нужно пройти 8 шагов, то каждый шаг - это как возведение в степень по количеству вариантов, а метод MITM (Meet In The Middle) идет с двух концов до середины, и в середине пересечение двух сетов находит - это позволяет отсечь 4 степени вариантов.
Получается, что в 500 раз - это ускорился поиск на моих цепочках. При удлинении цепочек ускорение будет расти.
У меня ускорял 500 раз. Сложный алгоритм последовательностей на графах. Сам я выжал всё, что знаю - минимум O, аллокаций, быстрые хеши, предельно сжатые в примитивы типы.
Но пришел Опус и в коде учел особенности графа, добавил MITM (Meet In The Middle).
То, что считалось неделю - посчиталось за 15 минут
Пытаюсь понять несколько вещей:
в чем ваша личная выгода транформации нарративов / что вы с этого получите
на кого это нацелено
чем вы их хотите мотивировать / что они с этого получат
Мотивации - вещь интересная
Хорошо. Мне кажется, что быть в тех категориях людей, которые эффективно используют токены - это большой плюс. Мне видится, что хорошо всем людям войти в эту категорию - я за этот хайп.
Если, гипотетически, все люди войдут в эту категорию, то верно ли я понимаю, что ваш посыл рефрейминга нарративов будет адресован никому, по принципу “для вас и ваших знакомых наверное не меняется”?
Спасибо за ответы! Встречные вопросы:
Всегда какие-то прфоессии устаревали - что именно вы предлагаете и кому именно? Например, что можно преложить разработчику, который покупает несоклько Max подписок?
Возможно дело не в названии. Мои знакомые попкупают не ИИ/AI, а вполне измеримые токены. Мне кажется, что им не важно как это называется.
На что это повлияет? Условно, я, покупаю токены Антропика и ОпенАИ - что меняется от того, что кто-то это как-то называет?
Спасибо за две копейки! Встречные вопросы:
В чем пузырь? Я знаю людей, которые покупают две MAX подписки, потребляют токены - а токены работают как три отдела программистов. Пузырь - это скорее про инвестиции, но разработчиков много идут к ним - просто покупают токены, это не вложения, а покупка реальной выгоды. Так же корпоративные игроки - много покупают токенов и реализуют выгоду. Если их отданные деньги потеряются - разработчикам и компаниям будет всё равно т.к они купили токены и реализовали их. Вопрос “Что конкретно выиграет общество” открыт и ждет ответа. Пузырь был в скобках вопроса - чтобы сразу отвести с него фокус, сфокусироваться на главной части вопроса, и получить ответ на главную часть - зачем кому-то брать эти нарративы.
Вопрос: в чем отличии тех, кто торопится от тех, кто не торопится? Это прямое следствие первого вопроса. Куда торопятся те, кто никак не в лидерах?
Если, условно, “вы” окажетесь в лидерах, то тоже перестанете торопиться сменить нарративы? И кажется Apple участвуют через сотрудничество т.к упустили момент стать лидерами, там же MS. И да, видно, что MS пытается тоже захватить право управлять нарративами.
Когда большие игроки,которые пропустили гонку, пытаются управлять нарративами - это понятно. Но когда мелкие игроки таются управлять нарративами - это хочу понять с их слов, какая у них мотивация.
Спасибо за статью! Если я правильно понял, в статье происходит столкновение нарративов и столкновение возможностей эти нарративы создавать и менять. Возникло три вопроса, буду рад узнать ваше мнение:
Что конкретно выиграет общество, если массово перейдёт на ваш прагматичный нарратив (помимо снижения рисков потенциального финансового пузыря)?
Почему, по вашему мнению, новые сильные игроки на рынке (например, разработчики Qwen или GLM) не пытаются сломать этот хайп и сменить правила игры, а продолжают играть по устовшимся правилам?
Логичное продолжение второго вопроса. А если представить, что сообщество трезвомыслящих людей (или вы лично) оказалось бы в позиции, где оно задаёт тон и смыслы индустрии по праву реального лидерства в мире, - стали бы вы целенаправленно менять нарративы, которые играют на вас лично, или достаточно просто называть вещи своими именами и ждать, пока рынок сам скорректируется?
По обоим вопросам - да, вы всё поняли правильно.
Кавычки - просто часть строки. В Ktav нет механизма квотирования ключей. “port” как ключ - это буквально пять символов, кавычки часть - имени. Именно это и произошло в вашем примере: “port” с кавычками внутри JSON стал ключом “port” с кавычками внутри Ktav.
Двоеточие - да, только :, других вариантов нет. Экранирование ключей (. : , { } [ ] \ \n \r) есть с 0.6.0.
По ошибке. Ваш service: abc писался верно, предупреждение - ложное. Заодно нашёл кое-что: бандл плейграунда не пересобирали после апдейта ядра до 0.6.3, сайт раздавал старый WASM. Починил и задеплоил, можно перепроверять на https://ktav-lang.github.io/. Спасибо!
Про JSON5-style кавычки - не подумали об этом на старте. Мне сейчас кажется даже странным, что упустили такое. Справедливо, действительно хочется опциональные кавычки. Не обещаю, но возможно сделаем в следующих версиях.
Завёл issue: https://github.com/ktav-lang/spec/issues/7
Добавить есть что - хорошо бы тесты добавть. Чужой код без тестов - как пыльный мешок с ножами. Вроде там что-то полезное, но трогать не хочется, а тем более нести.
Когда ИИ полностью создает продукт, то уже не хорошо поставлять продукт без тестов.
Одинарные скобки делают красивый триминг отступов когда можно сохранить целостность данных (в обратном конвертировании они значат, что отступы не нужны). Двойные - сохраняют строку как есть. Такой была цель.
Спасибо!
Это не пробел в спеке - она уже требует именно того, чего вам хочется. § 5.9.5(b) и § 5.9.7 прямо запрещают однострочную форму для строки с краевыми пробелами и обязывают многострочный блок ((…)) вместо неё.
Направление вы нащупали точно: ktav -> json у вас работает правильно, потому что там парсер, а он спеке следует. json -> ktav - это запись, и вот там баг: строка с пробелом по краям сейчас молча теряет байты вместо того, чтобы уйти в блок. Проверил на самом остром случае - строка “\ttrue”: вместо блока сейчас пишется однострочное field1:: true, а при обратном чтении ведущий таб пропадает вообще, значение схлопывается в чистое “true”. То есть это не просто некрасивая форма записи, а реальная потеря байта.
Этот же класс бага @chappihappymeal нашёл и прислал с PR, независимо от вас:
Issue: https://github.com/ktav-lang/rust/issues/3
PR: https://github.com/ktav-lang/rust/pull/4
Я прогнал ваш случай на ветке этого PR отдельно - чинит и его: та же строка с ведущим табом уходит в ((…)) и возвращается обратно байт в байт. Фикс идёт в ближайший патч-релиз 0.6.3, ничего не ломает - плейграунд подтянет его следующим обновлением вендоренного WASM.
И раз тема всплыла - параллельно копится пачка для отдельного релиза 0.7. Там уже прилично набралось: и спеку, и все семь парсеров гонять волной ради одной мелкой правки слишком дорого, поэтому такие изменения собираем до критической массы, а не выкатываем по одному.
Это будет масштабной работой. Не уверен, что возмусь за это, но мне нравятся ваши слова. В любом случае, это будет либо ktavPlus - вторым форматом (как TS над JS), либо обвязкой.
Оригинальный ktav очень хочу сохранить в простом виде - мне он тоже нравится именно своей простотой.
Если вы готовы быть поставщиком идей (в случае, если возьмусь) - создайте issue (https://github.com/ktav-lang/spec/issues). Если в будущем возьмусь, то я отпишусь под ним.
Спасибо - точное и ценное замечание, круто, что вы сразу нашли реальуню вещь, которая стоит доработки!
Это не пробел в спеке - она уже требует именно того, чего вам хочется. § 5.9.5(b) и § 5.9.7 прямо запрещают однострочную форму для строки с краевыми пробелами и обязывают многострочный блок ((…)) вместо неё. Отдельные кавычки не нужны - механизм для этого случая в формате уже есть, просто writer его не соблюдает.
Направление вы нащупали точно: ktav -> json у вас работает правильно, потому что там парсер, а он спеке следует. json -> ktav - это запись, и вот там баг: строка с пробелом по краям сейчас молча теряет байты вместо того, чтобы уйти в блок.
Этот же баг на этой неделе нашёл и прислал с PR @chappihappymeal - независимо от вас, через код.
Issue: https://github.com/ktav-lang/rust/issues/3
PR: https://github.com/ktav-lang/rust/pull/4
И раз тема всплыла - параллельно копится пачка для отдельного релиза 0.7. Там уже прилично набралось: и спеку, и все семь парсеров гонять волной ради одной мелкой правки слишком дорого, поэтому такие изменения собираем до критической массы
Почти) Только запятые были довеском - по-настоящему меня довели кавычки.
В JSON5 голым можно написать ключ, а значение всё равно в кавычках:
В Ktav кавычек нет ни в ключе, ни в значении, и корень не обёрнут в скобки - файл читается построчно:
Запятые ушли уже за компанию: раз пары и так разделены переносом строки, разделять их ещё и запятой стало не нужно.
Очень ценные запросы, спасибо! И почти всё здесь я готов подписать.
Про валидацию соглашусь. В другом комментарии я предлагал ровно то, что вы отвергаете - взять JSON Schema и проверять ей уже разобранный конфиг. Но тогда проверка идёт по готовым данным, в которых уже не осталось привязки к строкам файла. Подсветить ошибку в редакторе нечем.
Про остальные четыре пункта скажу прямо: этого нет. Почему - мы этим просто не занимались и не планировали заниматься. Формат отвечает на вопрос, как выглядит файл, а окружения, include и merge - это уже про то, как конфигурация собирается из нескольких файлов. Другой слой.
JSON и TOML останавливаются там же. Вы сами это отмечаете - и ваш тезис именно в том, что между форматом и полноценным инструментом остаётся дыра. С этим спорить нечего, дыра есть.
Мне кажется правильным закрывать её не изменением формата, а отдельной необязательной спекой поверх него: include как соглашение над обычными Ktav-документами, семантика глубокого merge (включая удаление ключа, а не только замену), выбор окружения, соглашение о ссылках на внешние секреты. Тогда файл остаётся обычным Ktav для тех, кому обвязка не нужна.
Завёл под это issue, расписал ваши пять пунктов как отправную точку: https://github.com/ktav-lang/spec/issues/5
Там же вынес открытые вопросы: своя схема или привязка к JSON Schema, отдельный документ или репозиторий, и стоит ли браться до 1.0 самого формата.
Это корректная форма ktav, спарсится в объект, который эквивалентен JSON:
Это можно в живую проверить на сайте ktav-lang.github.io
(на сложные случаи есть экранирование, но в малом ПО для конфигов это скорее всего не понадобится)