Тут есть сомнения, чт ов европах не окажется другого способа активации. Скажут используйте его, а если вы по каким-то религиозным причинам этого не хотите делать, то это уж ваши проблемы. Да и с неработающим способом можно сказать "ну баг, с кем не бывает. Низкоприоритетный, стоит в планах, лет через ...дцать починим. Безбажное ПО вам никто не обещал"
Поделать просто -- не пытаться компилировать все юниты компиляции в одной модели, а разделить -- это компилируем по старым правилам, а это по новым. Уровень оптимизации ведь для разных файлов по разному настраивать можно? Почему нельзя настроить и остальное? Просто удивительно, что все вокруг это уже поняли, и только Комитет упорно пытается впихнуть невпихуемое из года в год. Худо-бедно у него это получается, но все больше разработчиков вопрошает, что там курят.
Но в числе -2 нет i, а даже если и есть, то со множителем 0, что по вашим же словам означает поворот на 0 градусов (раз i это поворот на 90, а i/3 -- поворот на 30). Вот и объясните, как оно у вас поворачивается.
Что-то вы уперлись в свое вращение, хотя непонятно, что именно вращать-то, если у нас числовая прямая? Ну то есть вы просто с потолка взяли, что что-то там вращается, по мне, так это объяснение ничем не лучше. Почему вращается, почему именно настолько и почему в эту сторону? А обычные числа теперь как в квадрат возводятся? Что там вращается и насколько, что оказывается на положительной полуоси?
Да, это было бы интересно. Особенно, что так мешает для разных каналов использовать разный транспорт, чтобы там, где свойства TCP больше мешают, чем помогают, использовать UDP
А почему ухудшение-то? Вроде же наоборот, улучшение должно быть, мы ведь теперь не бегаем по всем вариантам в попытке найти правильный -- если вариант не подошел, то все...
Так я писал про то, что у вас в тексте явно скобки поплыли (буквально -- открывающая висит в показателе степени, закрывающая на уровне основного текста), к чему относятся значки радикалов, непонятно, где была степень -- непонятно, в одном месте 6 в 36 кажется превратилось. Сейчас уже поправлено, но вы правда думаете, что с замахом "объясню сейчас все четко и популярно" смазанный текст сослужит хорошую службу? А оправдываетесь тем, что мол, OCR подвел. Ну так у вас для этого глаза же есть, чтобы за ним проверить?
Ведь первую статью так хорошо начинали, и вот, не успели двух шагов пройти, а уже скатываетесь.
В смысле кажется? Вы же пишите статью для обучения, и надеюсь, прочитали то, что (вам) понаписали?
Что-то у меня после этих ваших заявлений очень сильный скепсис по поводу выполнения вами поставленной цели объяснить математику просто. Для этого в первую очередь ляпов не должно быть.
В дополнение можно указать, что ошибка, выдаваемая rust-peg, более простая, в сравнении с lalrpop - а именно, первый выдаёт только позицию и список ожидаемых токенов,
Зато вы можете самостоятельно перепарсить это место (т.е. начать разбор с указанного парсером места ошибки) уже другим парсером (даже PEG парсером, т.е. фактически другим правилом из той же грамматики) и получить то, что хотите. Хоть отдельный символ (хотя это и так уже есть по умолчанию), хоть слово (причем вы сами определяете, что такое "слово"). Более того, такие правила (на ошибочный вход), можно сознательно вставлять в грамматику в вероятных местах ошибки и прямо включать в выстраиваемый AST, чтобы потом обработать их на более верхнем уровне. Еще лучше, чтобы это делал парсер автоматически, но rust-peg этого (пока?) не умеет. Но если поинтересоваться темой, то люди делали такое для PEG парсеров и на хабре есть статья об этом.
Ваша идея довольно экстремальная - это ж придётся в процедурном макросе фактически произвести весь парсинг,
Так вы же и так это делаете в своем парсере MVL. Просто как я понял, сейчас вы запускаете генератор, он делает файлы, а потом эти файлы идут на вход компилятору Rust. Компилятор Rust вынужден эти исходники парсить, чтобы получить список токенов, которые потом он обрабатывает. А можно на вход компилятору сразу подавать список токенов.
разрешение идентификаторов, упорядочивание переменных по их зависимостям, аналитические и алгоритмические преобразования и оптимизации, и прочие операции.
А сейчас это кто делает? Ваш pipeline сейчас: (1)MVL -> (2)модель MVL в декларативных макросах Rust -> (3)декларативные макросы генерируют Rust код -> (4)компилятор Rust делает бинарник.
Я предлагаю убрать шаг 2 с сразу генерировать Rust код, как будто вы руками раскрыли макросы с шага 2, т.е. так: (1)MVL -> (2)процедурный макрос генерируют Rust код -> (3)компилятор Rust делает бинарник.
Как-то все же остались неясности, почему уже в самом описании парсера нельзя указать, тут name ключевое слово или нет. Ну то есть если в парсере в этом месте написано "name", то явно именна такая последовательность тут и ожидается и это ключевое слово. При этом оно ведь ожидается только в этом месте, в других местах вы спокойно в грамматике пишите <kw_name:id> и если там разбираемом тексте встретится name, оно будет как идентификатор распознано, а не ключевое слово. Или я тут чего-то не понимаю? Кстати, не смотрели на rust-peg?
Еще у вас получилось как-то странно: я так понял, вы написали парсер языка MVL, чтобы сгенерировать Rust-код на макросах, примерно повторяющем структуру исходного MVL, а в реализации макросов уже все делается. А почему бы просто не написать процедурный макрос, который принимает на вход MVL, а на выход дает Rust код, который это реализует?
Как использовать в сборке зависимости через rlib-файлы без исходников
Ну, просто в следствиях вы написали, что стало точнее. А это неправда (с численной точки зрения) и в скобочках можно было бы указать, что все было не так просто.
Тут есть сомнения, чт ов европах не окажется другого способа активации. Скажут используйте его, а если вы по каким-то религиозным причинам этого не хотите делать, то это уж ваши проблемы. Да и с неработающим способом можно сказать "ну баг, с кем не бывает. Низкоприоритетный, стоит в планах, лет через ...дцать починим. Безбажное ПО вам никто не обещал"
Поделать просто -- не пытаться компилировать все юниты компиляции в одной модели, а разделить -- это компилируем по старым правилам, а это по новым. Уровень оптимизации ведь для разных файлов по разному настраивать можно? Почему нельзя настроить и остальное? Просто удивительно, что все вокруг это уже поняли, и только Комитет упорно пытается впихнуть невпихуемое из года в год. Худо-бедно у него это получается, но все больше разработчиков вопрошает, что там курят.
Но в числе -2 нет i, а даже если и есть, то со множителем 0, что по вашим же словам означает поворот на 0 градусов (раз i это поворот на 90, а i/3 -- поворот на 30). Вот и объясните, как оно у вас поворачивается.
Что-то вы уперлись в свое вращение, хотя непонятно, что именно вращать-то, если у нас числовая прямая? Ну то есть вы просто с потолка взяли, что что-то там вращается, по мне, так это объяснение ничем не лучше. Почему вращается, почему именно настолько и почему в эту сторону? А обычные числа теперь как в квадрат возводятся? Что там вращается и насколько, что оказывается на положительной полуоси?
Да, это было бы интересно. Особенно, что так мешает для разных каналов использовать разный транспорт, чтобы там, где свойства TCP больше мешают, чем помогают, использовать UDP
Что, неужели абстракции в протоколе настолько протекают, что TCP не заменяется более-менее прозрачно на что-то другое?
А почему ухудшение-то? Вроде же наоборот, улучшение должно быть, мы ведь теперь не бегаем по всем вариантам в попытке найти правильный -- если вариант не подошел, то все...
Согласен, было бы интересно. Может сделаете?
Так я писал про то, что у вас в тексте явно скобки поплыли (буквально -- открывающая висит в показателе степени, закрывающая на уровне основного текста), к чему относятся значки радикалов, непонятно, где была степень -- непонятно, в одном месте 6 в 36 кажется превратилось. Сейчас уже поправлено, но вы правда думаете, что с замахом "объясню сейчас все четко и популярно" смазанный текст сослужит хорошую службу? А оправдываетесь тем, что мол, OCR подвел. Ну так у вас для этого глаза же есть, чтобы за ним проверить?
Ведь первую статью так хорошо начинали, и вот, не успели двух шагов пройти, а уже скатываетесь.
В смысле кажется? Вы же пишите статью для обучения, и надеюсь, прочитали то, что (вам) понаписали?
Что-то у меня после этих ваших заявлений очень сильный скепсис по поводу выполнения вами поставленной цели объяснить математику просто. Для этого в первую очередь ляпов не должно быть.
Зато вы можете самостоятельно перепарсить это место (т.е. начать разбор с указанного парсером места ошибки) уже другим парсером (даже PEG парсером, т.е. фактически другим правилом из той же грамматики) и получить то, что хотите. Хоть отдельный символ (хотя это и так уже есть по умолчанию), хоть слово (причем вы сами определяете, что такое "слово"). Более того, такие правила (на ошибочный вход), можно сознательно вставлять в грамматику в вероятных местах ошибки и прямо включать в выстраиваемый AST, чтобы потом обработать их на более верхнем уровне. Еще лучше, чтобы это делал парсер автоматически, но rust-peg этого (пока?) не умеет. Но если поинтересоваться темой, то люди делали такое для PEG парсеров и на хабре есть статья об этом.
Пример (в синтаксисе pegjs):
Как будто это что-то оправдывает
Сложным путем идет товарищ... Что мешало просто сохранить
findexв стеке Lua?Так вы же и так это делаете в своем парсере MVL. Просто как я понял, сейчас вы запускаете генератор, он делает файлы, а потом эти файлы идут на вход компилятору Rust. Компилятор Rust вынужден эти исходники парсить, чтобы получить список токенов, которые потом он обрабатывает. А можно на вход компилятору сразу подавать список токенов.
А сейчас это кто делает? Ваш pipeline сейчас: (1)MVL -> (2)модель MVL в декларативных макросах Rust -> (3)декларативные макросы генерируют Rust код -> (4)компилятор Rust делает бинарник.
Я предлагаю убрать шаг 2 с сразу генерировать Rust код, как будто вы руками раскрыли макросы с шага 2, т.е. так:
(1)MVL -> (2)процедурный макрос генерируют Rust код -> (3)компилятор Rust делает бинарник.
Как-то все же остались неясности, почему уже в самом описании парсера нельзя указать, тут
nameключевое слово или нет. Ну то есть если в парсере в этом месте написано"name", то явно именна такая последовательность тут и ожидается и это ключевое слово. При этом оно ведь ожидается только в этом месте, в других местах вы спокойно в грамматике пишите<kw_name:id>и если там разбираемом тексте встретитсяname, оно будет как идентификатор распознано, а не ключевое слово. Или я тут чего-то не понимаю? Кстати, не смотрели на rust-peg?Еще у вас получилось как-то странно: я так понял, вы написали парсер языка MVL, чтобы сгенерировать Rust-код на макросах, примерно повторяющем структуру исходного MVL, а в реализации макросов уже все делается. А почему бы просто не написать процедурный макрос, который принимает на вход MVL, а на выход дает Rust код, который это реализует?
Было бы интересно почитать
То есть сложный алгоритм на полтысячи строк не должен быть прокомментирован? Не завидую вашим читателям
Если верить квантовой механике, то как раз наоборот -- все в мире скачкообразно.
Гвоздь подвешен на нитке за острие.
Ну, просто в следствиях вы написали, что стало точнее. А это неправда (с численной точки зрения) и в скобочках можно было бы указать, что все было не так просто.
Ну-у-у, это и у математиков есть такая уязвимость. Наверное, поэтому им нобелевки не дают.</s>