АйТи притчи

Thoughts on Paths

2026-08-09T13:25:47.627Z

or what you need to know about using paths in a compiler

Алтай. Путешествие в самое сердце Сибири

Where It All Begins

What does the compiler know about its environment when it starts working?

Of what it guaranteed knows, one can only name the path to the binary file that served as the «launcher». How do we know this?

We know this from a convention that all operating systems I am aware of try to adhere to — at application startup, the path to the executable is passed as an argv parameter:

сКопировать

int main(int argc, char** argv) {
   ...
}

By convention, the zeroth element of the array passes a pointer to a string containing the path by which the program’s executable was launched — in our case, the compiler. Situations where this is not the case are possible, but have not been encountered in practice. Therefore, we proceed from the assumption that the compiler knows this.

Furthermore, other elements of this array may pass command-line parameters into the compiler. This information is also guaranteed to be available to the compiler.

All other information the compiler has to obtain itself.

Environment Information

What the compiler learns next, it finds out by querying the operating system.

The information to be discovered can be slightly grouped.

Here and further below, we speak of the compiler as a program; the issue of code generation and target platforms deserves separate consideration.

Operating System
For the compiler as a tool, knowledge of which OS we started on is not very interesting per se. It needs to be able to work with files and texts, and this, in turn, may depend on the operating system. Obvious among these dependencies is the structure of paths. In Windows, a path begins with a drive letter and a colon, like «C:». Different OSes use different path separators, «\» or «/», and in quite exotic cases, other types of separators might be used, and the way a filename is constructed differs significantly — for instance, the version might be part of the «filename.name; version».
Current Directory
It is not always needed, but we can only find out by asking the operating system. This information is already strictly platform-dependent; different platforms use different methods (different functions) to get the current directory.
Environment Variables
A lot of information in an OS is passed via a list of environment variables. This is a set of «name=value» pairs. Retrieving this list (or its individual elements) is also platform-dependent.

What the Compiler Needs to Work

Let us now enumerate what information the compiler needs to work. I will try to list as much as might be required; depending on the language and runtime properties, this list may change.

Moreover, I will mention degenerate cases I have encountered, as they provide a complete picture.

Location of the File Being Compiled
The file we intend to process is usually specified explicitly. That is, the path to this file is typically passed as a command-line parameter, but this is not necessarily so. For example, a compiler might be designed such that search paths matter to it, and only the filename is fed as input, while its location is determined by some predefined rules. Or, alternatively, the compiler might be configured to process a file whose location is hard-coded. In any case, the file (or another entity) with which the compiler’s work begins is the first and necessary piece of information for operation.
Location of Library Code
The compiler may require a set of entities used for handling the semantics of the language. This is «library» code and cannot be circumvented. It can be either part of the compiler or located externally.For example, Delphi has a module System.pas, which, if I remember correctly, wasn’t compiled but rather supplied so that «pseudo-definitions» would be available — i.e., entities (e.g., types) were implemented inside the compiler, yet they looked as if declared in a file.Haskell has a module Prelude, used during the compilation of any module.And so on; depending on the language, the workflow scheme may differ, but it is important to understand that we are talking about mandatory elements of language semantics. The presence of such modules is obligatory, and the compiler must be aware of them.
Imported Entities
Programs are rarely written without using external modules. Again, this is implemented differently across languages, but the general scheme is roughly the same. When an import or use operation appears in the source code (the specific term is not crucial right now), the compiler must go to some code repository and retrieve information about the imported module there.
Cached Imported Entities
Unlike the previous point, here we refer to entities that might have already been compiled and transformed into a form prepared for the final stages of compilation. We are talking about pre-compiled modules. Such entities can take up quite a bit of space and, in some cases, might even be located on a network and downloaded on demand. I did projects like this twice, and both times had to abandon them due to synchronization difficulties, timestamp management, and other technological complexities. However, the refusal was compensated by a general acceleration of compilation. Nevertheless, this group of artifacts must have its own access mechanism (and/or search).
Tooling
During compilation, not only the compiler’s own tools but also external auxiliary instruments may be used. Many compilers make calls to C/C++ compilers or their components. Calling assemblers, linters, checkers, and other tools is also possible here. And although in interactive mode it is almost always sufficient that these tools can be found via the system PATH, within CI/CD server builds this becomes highly non-obvious and often requires additional configuration or direct path specification.
Annotation Processors
Java and Lisp have mechanisms allowing intervention in the compilation process using code written in those languages (other languages feature this too, but less explicitly). And although formally one could say this falls under one of the previous definitions, such a tool might have its own setup and path-finding mechanism.
Target Storage
When compilation ends, the created artifact must be saved somewhere. This place where the file or files are saved can also be configured. For some compilers, saving happens next to the source text; for others, it can be set explicitly, and for still others, the storage of the compiled result is determined by calling a separate tool (jar in the same Java).
Secondary Artifacts
Compilation proper usually ends with creating an executable file. But a product rarely consists of just one file. There might also be media files, documentation, data files, UI files, etc. Furthermore, the compiler might include build management mechanisms and be capable of creating what are called «distributions». This, again, can be considered a tool invocation falling under item 5, or it can be part of the compiler, and where the distribution will be saved can and should also be configurable.

Where To Look?

Now let us talk about what the compiler can rely on while doing its job.

I can distinguish three mechanics that a compiler can use for its work: «portable build», «hard path», and «combined path».

Hard Path

Let’s start with the simplest, albeit very limited option — the hard path.

Such a compiler workflow scheme assumes that the entire compiler and all files for operation are located at a known, predefined path.

This scheme is good because all instrumentation can be reduced to a certain set of constants used everywhere. It is very convenient, allows one not to think about anything, and not to worry about placement.

Everything works fine until the question of cross-platform development or a significant change in environment arises.

Thus, back in the day, Windows systems noticeably complicated writing to disk root folders, which led to breakages in a large number of systems written based on the assumption that they would run from «C:\my_system\».

Moving to %USERPROFILE% didn’t change the situation much, as issues with long names and names with spaces began.

Furthermore, moving such a program to Linux or FreeBSD required non-trivial effort. Moreover, considering the differences between Unix-family operating systems, it often happens that a path exists and is accessible for execution on one OS, while on another it might be absent or present other difficulties, for example, requiring administrative access for normal operation.

Such a compiler workflow scheme generally has a right to exist, but requires a very clear understanding of the necessity to unify and control the environment in which this compiler operates.

Portable Build

This term emerged with the advent of USB drives, where the entire program could fit on that drive or in a separate folder on a hard disk. Such a program requires nothing to work; everything is located in one place.

With compilers, this scheme basically works well, with one small «but». During operation, the program might require a large amount of information, loadable modules, and other active development attributes, which will lead to a significant growth in the assembly contents, making it technologically very inconvenient to maintain.

Here perhaps a joke about the depth of a cave full of npm modules is appropriate, but it’s not really funny at all.

Therefore, although the scheme is generally viable, once the assembly size exceeds a certain threshold, it becomes burdensome.

Combined Path

The name of this mechanic is quite conditional.

One can somehow combine the previous two approaches — place part of the compiler, including possibly some library functions and other artifacts, so that the compiler gains access to them without ever referring to the OS, and place another part so that their usage, on one hand, does not depend on the compiler, and on the other hand, can be easily changed while maintaining operability.

For example, in the flow9 language, an interesting mechanic was applied.

The compiler serves as the foundation for product development, and all products are built around it. So, on the disk in the working folder, we see something like:

- flow
- product1
- product2 
...
- productN

and from any product folder, one can always call ../flow/bin/flowc main.flow, which will lead to product compilation and obtaining a distribution (I omitted a few details, but that’s essentially how it is).

Furthermore, if the code says import ds/list;, the compiler knows it needs to go to the ../lib/ds folder relative to its executable and grab the list.flow file from there.

Or, for example, in Go, there are environment variables GOROOT and GOPATH, defining, respectively, where the compiler’s binary files are located and where to look for files for compilation.

A similar function is performed by the combination of JAVA_HOME/CLASSPATH in Java. Although these are not the only variables that can be configured, these two substantially affect the compiler’s functionality.

At the same time, some files might be located in places with hard-coded paths. Thus, cached imported entities for ECL are stored in /home/user/.cache/common-lisp/ecl-23.9.9-9f27c69d-linux-x64/ and can be deleted at any time.

Rust, for example, stores imported modules in the ~/.cargo folder.

And so on.

How to Use This

What can the compiler use to gain access to the required entities?

path to its own executable file
contents of environment variables, GOPATH or CLASSPATH
a config file located at a known address, e.g. ~/.sbclrc or %USERPROFILE%/my.cnf
a config file defined within the compiler
a config file defined in the project
parameters passed via the command line
parameters embedded in files during installation (Go does this, for example)
dynamically changing parameters, if the system allows it

If several of the listed configuration methods are used, a priority system must definitely be established for them, meaning some should have higher «importance» than others, which will allow resolving conflicts if multiple ways of specifying settings are indicated simultaneously.

Conclusion

All of the above is intended so that when working on your next compiler, you have arguments for choosing the layout scheme for parts and libraries.

The list of used entities and configuration methods depends significantly on incoming requirements, and maximum flexibility is not always required, but limiting oneself to just one thing is usually not worth it either.

Вывод элементов списка через запятую

2025-11-22T11:03:18.380Z

Вот регулярно надо, и все время забываю, как это делается.

А просто надо использовать шапку:

(format nil "~{~A~^, ~}" (list 1 2 3 ))
"1, 2, 3"

Вуаля!

От «творчества» ИИ воняет за километр

2025-08-24T02:38:47.041Z

Копия статьи Игоря Мальцева, vz.ru

Можно, конечно, сломать ход истории, подойти и плюнуть на картину Малевича, и это тоже будет актом художественного творчества — акционизмом. Но слабая сторона ИИ в том, что он даже этого сделать никогда не сможет.

Нам рассказывают про то, как ИИ стремительно идет в территорию вдохновения, в творчество, в частности в изобразительное искусство и музыку.

У меня плохие новости для верящих в данный маркетологический прогон.

Публика, которая верит в то, что ИИ может создать оригинальное произведение, просто пребывает в иллюзиях, что искусство — бесконечно. Но это просто от незнания, ничего страшного. Хотя нет. Страшновато.

Как ИИ на выдаче в поисковике паразитирует на том, что собирали и писали живые профессиональные люди на разных ресурсах, таким образом обкрадывая целые издательские дома, точно так же в изо и музыке ИИ тупо паразитирует на всем наследии творческого человечества. А оно — конечно.

Ведь вы не задумываетесь о том, что музыка имеет очень жесткие законы, в том числе физические и математические, и все они исследованы до последнего герца (440 Hz — нота «ля»).

Законы квинто-квартового круга, из которого не вырваться. Тон-тон, полутон, три тона-полутон. Кто учил, тот в курсе. Ведь наш гений не зря писал: «поверил алгеброй гармонию». Вариантов гармонических последовательностей настолько мало, что на самые популярные из них, скажем, в интервалах IV–I-II–V, написаны сотни произведений, начиная с «Канона ре мажор» Иоганна Пахельбеля до «Гимна Советского Союза» и Let it Be группы Beatles. Aerosmith с Green Day не упоминать. Четвертая-первая-вторая минор-пятая. Уныло до невозможности. Бесконечные G — D — Em — C. Но есть нюансы.

Мощный ИИ напишет вам еще тысячу песенок на IV–I-II–V. И он будет собирать мозаику из аранжировок, звучаний, обрывков мелодий, существующих записанных человеческих голосов, безусловно ограниченных тюремными законами гармонии, и создаст еще одну тонну мусора. Две тонны. То есть он делает то, что малоталантливые живые авторы делали все эти годы — строго в соответствии с законами музтеории и музпрактики, плюс мода, плюс конъюнктура, плюс жрать хочется. Просто ИИ может сделать это быстро и много.

Собственно — последнее «Евровидение» всё звучало, как продукт ИИ. Симпатичная, правильная полная бессмыслица.

Любой дурак сыграет в подворотне IV–I-II–V в той или иной тональности. Но только у Пола Маккартни получилась Let It Be. А у Александрова — «Союз нерушимый».

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

А у цифирок с душой напряженка.

А ведь живые люди уже переступили строгие законы квинто-квартового круга и создали новые — Венская школа с Шенбергом расправилась с законами, по которым писал Моцарт, и открыла врата Густаву Хольсту, а тот — Black Sabbath и так до полной деконструкции и мелодии, и гармонии, но тоже в новых, очень строгих рамках.

Всё уже написано и записано человечеством. А кого и это не устраивало — тот Карлхайнц Штокхаузен с Джоном Кейджем. Зато на них выросли все «Крафтверки» Германии и вся электронщина мира.

И на всем этом тоже вынужден паразитировать бездушный ИИ. Прекрасный пример — недавний хайп стопроцентной ИИ-группы Velvet Sundown на Spotify. Причем только человеку без ушей и без музыкальной памяти непонятно, что это ИИ.

Как отличить фальшивые надувные шарики? А они точно такие же, только не радуют.

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

Но потом начнется самое интересное: он, ИИ, переварит все то, что сделано людьми, а потом ему придется переваривать уже то, что создано ИИ.

И по всем природным законам — продукт пищеварения, еще раз переваренный, остается все той же субстанцией.

И поэтому так воняет за километр от «художественного творчества» ИИ. Он вынужден переваривать то, что уже придумано людьми за всю историю художественного творчества. А придумано человеком уже буквально всё, что можно изобразить при помощи материалов — осталась одна Марина Абрамович. Да и та скисла, старушка. Провокаторов и без нее хватает.

С каким-то дикарским восторгом в рамках строгого карго-культа неофиты от нейронок ходят буквально под себя, когда им удается получить смешную картинку Йоды в стиле ван Гога. Или «оживить» картину Васнецова. Да, печальный факт — люди знают обычно всего два-три имени и три-четыре стиля и в рамках своих знаний «творят» при помощи нейронок. Насытившись «приколами», начинают генерить портреты шестипалого себя «в стиле».

И это невозможно видеть глазами. Они кровоточат.

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

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

Не случайно же есть идиотское выражение, что мы живем в эпоху постомодерна (выпендрялы еще придумывают всякие новые приставки к корню «модерн») — то есть пережевываем по сотому разу всё, что создали предки — начиная с того, который выскребал на стене пещеры бегущих оленей оленьей же костью.

Придумано всё. Буквально.

Потому что у изобразительного искусства все те же строгие законы. Все цветовые закономерности исследованы до последнего пантона, все формы и антиформы уже создали Ван Дейк с Джексоном Поллоком (и сто тыщ авторов между ними). А искусство еще живо — хотя бы потому, что есть руки, голова и магия материала.

ИИ лишен рук, материала — красок, кистей или просто ведра для разливания пигмента по холсту, как у Поллока. А фактура, отражение света и даже запах краски — это все составляющие, без которых изображение становится репродукцией в журнале «Огонек».

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

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

Потому что все происходит быстро. Очень быстро. В гигантских объемах. И формальное развитие идет очень быстро. Только развиваться некуда.

Ну хорошо, посчитаете себя остроумным, напишете ИИ промпт: «Нарисуй заседание центробанка в стиле Мэн Рэя и Караваджо одновременно». Вау, как смело.

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

Потому что было уже всё. Стоило Малевичу намалевать черный квадрат, как обязательно найдется какой-нибудь Марк Ротко, который нарисует черных, красных и синих прямоугольников штук тридцать и будет продаваться за миллионы и висеть в музеях. Не потому, что публика — дура. А потому, что старик Ротко тоже вложил что-то в идиотский черный квадрат. Наверное, это называется «человеческая душа».

Можно, конечно, сломать ход истории, подойти и плюнуть на картину Малевича, и это тоже будет актом художественного творчества — акционизмом. Но слабая сторона ИИ в том, что он даже этого сделать не сможет просто никогда. Даже при помощи андроида.

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

— А-а-а! — кричат они — Вышла новая версия Reve 1.0 — вы только посмотрите-посмотрите, вы еще быстрее сделаете видео со старухой и бегемотом и порвете видеоплатформы на миллионы просмотров!

— Или вот! — Новая эра создания видео и игры Genie — всего за 200 долларов подписки! О-о-о!

Причем с таким видом, как будто все приблуды внутри нейронки разработали они лично, а не анонимные индусы из Кремниевой долины. Как шаманы. Помните, как быстро появились «евангелисты» какого-нибудь «Клабхауса» или НФТ — и куда они все делись?

Так и здесь — восторг от того, что можно вспомнить самую тупую шутку и сгенерить на нее видео с участием модного реального актера из «Марвела». Эта мысль приводит публику в состояние исступления. И публика платит. Надеется порвать интернет и наконец стать хозяином востребованного контента.

Срочно бежим на VEO-3! И будет нам счастье и деньги. Завтра выйдет еще пять инструментов, которые для профессиональной работы пригодны так же, как айфон для свадебной фотографии. А со всех сторон несется — «промпт тебе напишет Чат ДжиПи-Ти — даже не надо думать самому, потом заваливаешь в Мидджорни, а потом в ВЕО ТРИ!».

Дерзай, вперед! Две старухи на самокате! Уморительно смешно! Естественно, стоит увеличить результат «творчества» хотя бы до размеров ноутбучного монитора, то качество картинки посыплется сразу — видно, что это все отвратный ИИ.

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

Это как со смартфонами — у всех есть камеры, кругом миллиарды камер, но когда что-нибудь случается — отовсюду нам показывают только мутные видео и бегущие ноги, и даже простые фотки — абсолютно нечитаемые. Даже неподвижный вулкан со столбом пламени внятно снять никто не может. Так и ИИ-видео — только для заработков единиц на очередном «тубе» или тиктоке, пока миллионы чайников платят за подписки на эти инструменты.

Революция отменяется. Без души ничего не работает.

Иногда надо чистить даже лазерные мыши и трекболы

2025-05-15T08:59:46.544Z

Довольно давно я переложил мышку под левую руку, а потом и вовсе заменил ее на трекбол. Вот такой:

Это Kensington Expert Mouse Trackball. Все в нем замечательно, но со временем появилась проблема — стал останавливаться курсор мыши. Крутишь шар, а мышка на экране не движется. Лечится перетыканием USB разъема.

Честно говоря, думал деградация электроники. При этом я трекбол регулярно чистил, разумеется, но только снаружи.

Естественно, что я такой был не один. На Reddit'е народ жалуется, производителю пишут, на Амазон возвращают.

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

В итоге, случайно, на одном из форумов (они еще живы!) прочитал о том, что у пользователя трекболы этой марки уже больше 15 лет, и что их просто надо эпизодически разбирать и чистить.

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

И, о чудо!, устройство перестало терять курсор. Даже, кажется, быстрее работать стало!

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

Век живи, век учись...

Оптимизация хвостовой рекурсии в трансляторе

2024-11-28T14:16:54.726Z

Копия моей статьи 2018 года. В принципе, актуальности не потеряла.

О чем это вообще?

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

Сложности начинаются тогда, когда приходится отображать функциональный подход на императивный. Так, если есть необходимость организовать компиляцию из функционального языка в императивный, например ML в Java или JavaScript.

Проблема рекурсивных вызовов в том, что на вызов тратится место в стеке вызовов, т. к. каждый новый рекурсивный вызов, помимо затрат на исполнение тела функции, дополнительно сохраняет точку возврата из текущей функции.
А в рекурсивных алгоритмах количество вызовов может быть большим или очень большим. Стек вызовов исчерпывается очень быстро. Частичным решением служит увеличение размера стека вызовов, однако практически это слабо помогает.

Что сложного то?

Практический размер стека вызовов редко превосходит несколько тысяч элементов. Это не позволяет делать, например, рекурсивный обход больших бинарный деревьев. И если на императивных языках это можно исправить путем переписывания рекурсивного алгоритма в явно циклический алгоритм (обычно за счет существенного его усложнения), то в функциональных языках избавиться от рекурсии бывает сложно или вообще невозможно.

Перейдем к ~~кошкам~~ примеру.

Есть функция for():

// Flow9
for (init, predicate, fn) {
    if (predicate(init))
        for (fn(init), predicate, fn)
    else init
}

Транслятор переведет ее в Java или JavaScript один в один, никакой магии (приведен код на Javacript):

// JavaScript
function for__(init, predicate, fn) {
        if (predicate(init)) {
            return for__(fn(init), predicate, fn);
        } else {
            return init;
        }
    }
}

Она даже синтаксически будет выглядеть практически также.

Разумеется, на той же Java эту функцию вполне можно заменить обычным циклом. Но мы же в трансляторе это делаем, нам нужен автоматический перевод, верно?

Поэтому мы получим рекурсивный вызов. Ну и следом во время выполнения получим исчерпание стека вызовов.

Что делать? Спасите, помогите!

Чтобы исправить ситуацию и как-то заставить это работать, разработана техника, позволяющая экономить место в стеке вызовов или избавиться от рекурсивных вызовов вообще.

Мы модифицируем функции таким образом, чтобы изменить рекурсивный вызов на цикл. Это возможно, но, к сожалению, заменить можно не все рекурсивные вызовы. Так, чтобы вызов функции можно было заменить на итерацию цикла, нужно соблюсти несколько условий:

вызов функции должен быть последним в последовательности операций;
это должен быть именно рекурсивное обращение к функции, без каких-либо дополнительный операций (например, в вычислении факториала, куда уж без него! , выражение n*fac (n-1) нельзя автоматически заменить на циклический вызов);
вызов функции не может быть вложен в замыкание, т. е. в случае с for() конструкция for(..., \x->for()..., ...) не будет заменена на циклическую.

Выполнения этих условий достаточно, чтобы рекурсивный вызов можно было заменить на итерацию цикла. Из-за первого условия (вызов находится в конце последовательности) это явление получило название «хвостовая рекурсия».

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

Есть масса способов это сделать, на просторах Интернета можно найти разные решения.

Я покажу два решения, которые успешно применяются в трансляторах.

Решение первое

Функция предварительно готовится с помощью вспомогательной операции:

// JavaScript
function TCO(fn, fn_name) {
    var top_args;
    window[fn_name] = function() {
        var result, old_top_args = top_args;
        top_args = arguments;
        while (top_args !== null) {
            var cur_args = top_args;
            top_args = null;
            result = fn.apply(null, cur_args);
        }
        top_args = old_top_args;
        return result;
    };
    window['tc_' + fn_name] = function() {
        top_args = arguments;
    };
}

TCO((init, predicate, fn) => {
    if (predicate(init)) {
        return tc_for__(fn(init), predicate, fn);
    } else {
        return init;
    }
}, 'for__');

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

Метод работает безупречно, правда медленно. Виной тому использование метода не самого быстрого метода fn.apply(). В Java используется рефлексия, которая тоже дает падение производительности.

Этих недостатков лишен второй метод.

Решение второе

Поскольку речь идет о внутренностях транслятора, мы многое знаем о модифицируемой функции. Создадим явный цикл и будем самостоятельно заниматься модификацией аргументов.

// JavaScript
function for__(init, predicate, fn) {
    T: while (true) {
        if (predicate(init)) {
            let $a_ = fn(init);
            let $b_ = predicate;
            let $c_ = fn;
            init = $a_;
            predicate = $b_;
            fn = $c_;
            continue T
        } else {
            return init;
        }
    }
}

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

Очевидную оптимизацию с неизменяемыми аргументами (см. $b_ = predicate;) оставлю пытливому читателю для самостоятельного изучения.

Поскольку технически рекурсивный вызов функции отсутствует, этот метод существенно производительнее предыдущего. В большинстве случаев это работает хорошо. Однако мы столкнулись с интересной проблемой, заставившей изрядно поломать голову.

Неожиданная проблема

Есть функция, в которой хвостовой рекурсивный вызов параметром получает функцию.

Модификации аргументов в приведенном методе недостаточно, если в рекурсивный вызов уходит замыкание, использующее аргументы исходной функции.

// Flow9
main() {
    recursiveFn(1,  \res -> println("Внешний вызов. Результат = " + int2str(res)));
}

recursiveFn(counter : int, onOK : (int) -> void) -> void {
        println("Шапка recursiveFn. Counter = " + int2str(counter));

        if (counter > 1) {
                println("Первая ветка recursiveFn. Counter = " + int2str(counter));
                onOK(counter)
        } else {
                println("Вторая ветка recursiveFn. Counter = " + int2str(counter));
                recursiveFn(counter + 1, \newCount -> {
                        println("Внутренний вызов. newCounter = " + int2str(newCount));
                        onOK(newCount);
                });
        }
}

Ключевой момент — вызов функции onOK после println("Внутренний вызов. newCounter = " + int2str(newCount)).

Если мы, что называется, в лоб, преобразуем функцию в JavaScript, результатом будет бесконечная рекурсия.

// JavaScript
function main() {
    return recursiveFn(1, ((res) => {
        return println(("Внешний вызов. Результат = " + int2str(res)));
    }));
}

function recursiveFn(counter, onOK) {
    T: while (true) {
        println(("Шапка recursiveFn. Counter = " + int2str(counter)));
        if ((counter > 1)) {
            println(("Первая ветка recursiveFn. Counter = " + int2str(counter)));
            return onOK(counter);
        } else {
            println(("Вторая ветка recursiveFn. Counter = " + int2str(counter)));

            let $a_ = ((counter + 1) | 0);
            let $b_ = ((newCount) => {
                println(("Внутренний вызов. newCounter = " + int2str(newCount)));
                return onOK(newCount);
            });
            counter = $a_;
            onOK = $b_;
            continue T
        }
    }
}

Неважно что будет стоять после строки println(("Внутренний вызов. newCounter = " + int2str(newCount))), onOK или $b_. Мы получим бесконечную рекурсию из-за того, что замыкание использует внешнее значение функционального параметра onOK.

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

// JavaScript
function main() {
    return recursiveFn(1, ((res) => {
        return println(("Внешний вызов. Результат = " + int2str(res)));
    }));
}

function recursiveFn(counter, onOK) {
    T: while (true) {
        println(("Шапка recursiveFn. Counter = " + int2str(counter)));
        if ((counter > 1)) {
            println(("Первая ветка recursiveFn. Counter = " + int2str(counter)));
            return onOK(counter);
        } else {
            println(("Вторая ветка recursiveFn. Counter = " + int2str(counter)));

            let $_ta = onOK;
            let $a_ = ((counter + 1) | 0);
            let $b_ = ((newCount) => {
                println(("Внутренний вызов. newCounter = " + int2str(newCount)));
                return $_ta(newCount);
            });
            counter = $a_;
            onOK = $b_;
            continue T
        }
    }
}

Внимание следует обратить на переменную $_ta, которая уже внутри замыкания используется вместо onOK.

При трансляции мы модифицируем лексическое окружение для генерации кода замыкания. После генерации тела замыкания лексическое окружение восстанавливается, чтобы не поломать нижележащий код. Это делается тем же способом, что и генерация кода для рабочих серверов (в неотладочном режиме).

Этот метод трансляции работает корректно и уже используется в боевых системах.

И что, вот так вот и работает?

Трансляция хвостовой рекурсии еще споткнулась о ключевые слова. Если посмотреть на определение функции for() выше, то можно увидеть, что в результирующем коде стоит название for__(). Транслятор не видел измененное имя и, соответственно, не помечал его как рекурсивный вызов.

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

Важные языки. Часть 1. Forth

2024-10-20T17:11:29.226Z

Этой статьей начинаю краткий цикл о трех языках программирования, знакомство с которыми считаю очень важным для любого профессионала в программировании: Форт, Лисп и Оберон.

Сразу оговорюсь, что я не призываю на этих языках разрабатывать, нужны очень веские причины, чтобы принять такое решение. Но знакомство с ними — важная часть профессионального роста.

Историческая справка

4 октября 1957 году Советский Союз запустил в космос первый искусственный спутник земли, а затем 3 ноября 1957 года — второй спутник. Это были события поистине планетарного масштаба! Победа советской научной и технической мысли, результат титанических усилий тысяч ученых и инженеров. Мы по праву гордимся этим достижением и по сей день.

У конкурирующей же стороны, американцев, еще не было своих спутников (появятся позже), они очень внимательно следили за советскими. Научное сообщество всего мира собирало данные о полете спутников, проводило расчеты и пыталось предсказывать траекторию движения, параллельно подстраивая расчетные методики. Помимо расчета положения спутника (расчета эфемерид и других данных полета), ученые проводили изучение ионосферы Земли, поскольку данные передатчиков, излучающих знаменитое «Бип! Бип!» были известны. На основе наблюдений и расчетов было сделано много научных открытий.

Занималась этим и Смитсоновская астрофизическая обсерватория, где работал Чарльз Мур, позднее ставший создателем языка Форт.

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

На странице 30 отчета (страница 175 в PDF) приведена статья «Predictions for Photographic Satellite Tracking Stations — APO Ephemeris 4» за авторством Чарльза Мура (физика-ассистента) и Дона Лаутмана (математика). В этой статье описывается программа Ephemeris 4 для компьютера IBM EDPM 704, предсказывающая положение спутника для использования следящими станциями.

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

Как позже сам Мур напишет в статье The Evolution of Forth, чтобы избежать постоянной перекомпиляции исходных текстов программы, он реализовал простой интерпретатор, читающий входные данные с карт. Это позволило компоновать уравнения для разных спутников без повторной компиляции.

Интерпретатор предоставлял несколько команд и концепций, перекочевавших в современные реализации Форта. Использовалась команда чтения «слов», разделенных пробелами, команда преобразования чисел из внешнего во внутреннее представление (по всей видимости имеется ввиду лексический разбор — прим. авт.), а также конструкт IF ... ELSE ....

Мур обнаружил, что свободное форматирование кода может быть и более эффективным (код меньше и производительнее), и более надежным в сравнении с распространенным в то время колоночным расположением кода на Фортране.

После завершения учебы Мур в работе использовал разные языки программирования: ALGOL, JOVIAL, PL/I, FORTRAN и всевозможные ассемблеры, не оставляя, тем не менее, идеи использования интерпретатора, который он «таскал с собой, буквально нося пачку перфокарт» (прямая цитата — прим. авт.)

Из языков программирования Мур заимствовал идеи в свой интерпретатор, реализуя с его помощью все более сложные программы. Так появились кросс-ассемблер, примитивный редактор и система управления исходниками. Кроме того, он создал программу для генерации анимированных 3D изображений и шахматную программу, а также игру Spacewar. В интерпретатор добавился стек значений, переменные, арифметические операции и операции сравнения, возможность задания процедур.

В это время появляется название FORTH. Оно отсылает к четвертому поколению компьютеров, как тогда называли маленькие компьютеры. Буквой U из слова FOURTH (четвертый) пришлось пожертвовать из-за того, что файловые системы того времени не позволяли использовать имена файлов длиной более 5 символов. Написание Forth (без капитализации) появилось значительно позже, опять же благодаря файловым системам, способным различать строчные и заглавные буквы.

Важной вехой стало появление «словаря». Это отдельная сущность, в которую помещались имена процедур вместе с указателем на код, который их реализует. Фактически это была реализация «косвенного шитого кода», осуществленная за 5 лет до появления этого термина.

Наконец, последней концепцией, дополнившей картину Форта стала идея отдельного «стека возвратов», упростившего использование данных и процедур, без необходимости балансировать стек до/после вызова процедуры.

Философия Мура

Для Мура Форт был личным ответом на разочарование от современного ему программного обеспечения, которое он называл «Вавилонской башней»:

The software provided with large computers supplies a hierarchy of languages: the assembler defines the language for describing the compiler and supervisor; the supervisor the language for job control; the compiler the language for application programs; the application program the language for its input. The user may not know, or know of, all these languages: but they are there. They stand between him and his computer, imposing their restrictions on what he can do and what it will cost.

And cost it does, for this vast hierarchy of languages requires a huge investment of man and machine time to produce, and an equally large effort to maintain. The cost of documenting these programs and of reading the documentation is enormous. And after all this effort the programs are still full of bugs, awkward to use and satisfying to no one.

Вольный перевод:

ПО, предоставляемое с большими компьютерами привносит иерархию языков: ассемблер определяет язык для описания компилятора и супервизора; супервизор — языки для управления заданиями; компилятор — язык для приложений; приложения — входной язык для данных. Пользователь может не знать все языки или знать не все языки, но они присутствуют. Языки находятся между пользователем и его компьютером, выставляя собственные ограничения того, что можно делать и ожидаему стоимость решения.

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

С религиозной настойчивостью Мур отстаивал принцип «Keep it simple!», считая его «Основополагающим принципом». Не без оснований он считал, что для многих задач Форта достаточно.

С этим можно спорить, но Мур был последователен в отстаивании своих принципов. Он реализовал Форт для 18 разных ЦПУ, писал весь требуемый инструментарий, включая кросс-ассемблеры, драйверы и т.д.

Мур был очень требователен к ПО, которое он разрабатывал. Многократно перерабатывая и улучшая Форт, он добивался того, что система выполняла требуемые функции, оставаясь при этом маленькой, эффективной и гибкой.
Гибкость Форта вместе с его интерпретируемой природой показали огромную эффективность и впечатляющие результаты во многих приложениях.

Важность Форта

Форт очень простой язык, и ценность его для программиста состоит в том, что он позволяет практически дотронуться до нескольких концепций, лежащих в его основе.

Интерпретация

Код на Форте интерпретируется. Каждое «слово» на языке исполняется либо кодом внутри интерпретатора, либо комбинацией других «слов». Понимание этого механизма позволяет лучше разбираться в системах, которые используют подобные техники. Так, то, что сейчас называется intrinsic в виртуальных машинах или в других системах, где есть сколь-нибудь сложный рантайм, корнями уходят в том числе в Форт.

Стек значений

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

Словари

Структура, отображающая имя в какую-то другую сущность, сегодня, кажется, проникла во все языки программирования в том или ином виде, однако, в Форте она имеет особое значение. Словарь является более высокоуровневой сущностью, по сравнению со «словом». Он может быть наделен своей семантикой и в программе может быть разное количество словарей.

Простота реализации

Интерпретатор Форт можно реализовать за один-два вечера. Причем это будет полноценная реализация.

Современные реализации

Сегодня сам по себе Форт используется нечасто. Однако идеи этого языка и того, как он реализован используются очень много.

Так, PDF и PostScript — это прямые потомки языка Форт. Во FreeBSD с версии 3.1 до версии 12 в загрузчике использовался интерпретатор Forth (позже заменен на Lua). Уже упомянутые стековые виртуальные машины используют идеи Форта.

TON Blockchain внутри использует Форт-подобный язык и стековую машину.

Не могу не упомянуть российскую разработку — SP-Forth и разработку российского разработчика по рождению Славы Пестова Factor.

Надеюсь, эта информация поможет расширить ваш программный инструментарий!

Чертежи в SVG формате. Часть 3 — Черновик стандарта

2024-06-05T11:21:11.521Z

В "Чертежи в SVG формате. Часть 2 — Черновик стандарта" приведён пример рисование простых графических объектов из CAD систем. В продолжении рассмотрим рисование штриховки для разных материалов.

Штриховка

Шаблон штриховки рисуем в defs части чертежа используя тег pattern.
Шаблон для штриховки металла (тип 0) под углом 45°.

<pattern id="hatch0_45" width="20" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="1" y1="20" x2="20" y2="1" />
    <line class="line-type-2_025" x1="0" y1="1" x2="1" y2="0" />
</pattern>

Многие заметят и зададут вопрос, зачем нарисовано две линии вместо одной с координатами x1="0" y1="20" x2="20" y2="0"?
Пример штриховки с одной линией в шаблоне

если внимательно присмотреться то увидим разрывы в линии штриховки.
Пример штриховки с двумя линиями в шаблоне

с двумя линиями таких разрывов нет.

Фрагмент кода области заштрихованной типом металл под углом 45°.

<path d="M475,225 L475,325 L500,325 L500,225 Z" fill="url(#hatch0_45)"/>

Шаблон для штриховки металла (тип 0) под углом 30°:

<pattern id="hatch0_30" width="34" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="2" y1="20" x2="34" y2="1" />
    <line class="line-type-2_025" x1="-1" y1="2" x2="3" y2="-1" />
</pattern>

Примеры штриховки других материалов:

Шаблон для штриховки неметалла (тип 1) под углом 45°:

<pattern id="hatch1_45" width="34" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025 " x1="0" y1="20" x2="20" y2="0" />
    <line class="line-type-2_025 " x1="0" y1="0" x2="20" y2="20" />
</pattern>

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

<pattern id="hatch2_45" width="350" height="350" patternUnits="userSpaceOnUse">
    <circle class="line-type-2_025" cx="0" cy="0" r="180" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="200" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="220" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="240" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="260" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="280" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="300" fill="none"/>
    <circle class="line-type-2_025" cx="0" cy="0" r="320" fill="none"/>    
</pattern>

Шаблон для штриховки камня естественного (тип 3) под углом 45°

<pattern id="hatch3_45" width="20" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025 " x1="0" y1="20" x2="12" y2="8" />
</pattern>

Шаблон для штриховки керамики (тип 4) под углом 45°

<pattern id="hatch4_45" width="20" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="0" y1="16" x2="16" y2="0" />
    <line class="line-type-2_025" x1="4" y1="20" x2="20" y2="4" />
    <line class="line-type-2_025" x1="0" y1="4" x2="4" y2="0" />
    <line class="line-type-2_025" x1="16" y1="20" x2="20" y2="16" />
</pattern>

Шаблон для штриховки бетона (тип 5) под углом 45°

<pattern id="hatch5_45" width="20" height="20" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="0" y1="30" x2="6" y2="24" />
    <line class="line-type-2_025" x1="10" y1="20" x2="26" y2="4" />
</pattern>

Шаблон для штриховки стекла (тип 6) под углом 45°

<pattern id="hatch6_45" width="30" height="30" patternUnits="userSpaceOnUse">
    <line class="line-type-2_025" x1="5" y1="15" x2="13" y2="7" />
    <line class="line-type-2_025" x1="5" y1="25" x2="25" y2="5" />
    <line class="line-type-2_025" x1="17" y1="23" x2="25" y2="15" />
</pattern>

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

<path class="line-type-2" d="M0,575L0,600 15,675 100,650 250,675 300,575z"/>
<path d="M0,575L0,600 15,675 100,650 250,675 300,575z" fill="url(#hatch0_45)"/>
<circle class="line-type-2" cx="150" cy="625" r="40"/>
<circle cx="150" cy="625" r="40" fill="white"/>

Область окружности накладывается на заштрихованную область.

Чертежи в SVG формате. Часть 2 — Черновик стандарта

2024-05-30T12:07:41.488Z

В "Чертежи в SVG формате. Часть 1 — Черновик стандарта" приведён пример объектной модели чертежа, задания масштаба и стилей линий. В продолжении рассмотрим рисование простых графических объектов из CAD систем.

Простые графические объекты

В CAD системах используются следующие простые графические объекты:

Точка (маркер)

Шаблон и стили отображения точки мы рисуем в defs части чертежа.

<marker id="Point0" viewBox="-10 -10 20 20" markerWidth="5" markerHeight="5">
  <path d="M-3,0 L0,-3 3,0 0,3 z" stroke="red" fill="none"/>
</marker>

Выводим точку в чертеже с помощью тега path. В свойстве stroke-width задаём обратный масштаб вида, если масштаб вида 1:4, то для точки указываем масштаб 4:1.

<path stroke-width="4" d="M50,35" marker-end="url(#Point0)"/>

Линия

В CSS файле описываем типы линий.

line, rect, circle, ellipse, path, text {
  vector-effect: non-scaling-stroke;
}
/* основная */
.line-type-1 {
  fill: none;
  stroke: blue;
  stroke-width: 2;
}
/* тонкая */
.line-type-2 {
  fill: none;
  stroke: black;
  stroke-width: .7;
}
/* осевая */
.line-type-3 {
  fill: none;
  stroke: red;
  stroke-width: .7;
  stroke-dasharray: 25, 4, 3, 4;
}
/* штриховая */
.line-type-4 {
  fill: none;
  stroke: black;
  stroke-width: .7;
  stroke-dasharray: 7, 4;
}
...

А в чертеже используем тег line с присваиванием ему класса типа линии.

<line class="line-type-1" x1="0" y1="0" x2="500" y2="0"/>

Для тега line задано свойство vector-effect с значением non-scaling-stroke. В любом заданном масштабе для вида линии будут отрисовываться с одинаковой толщиной.

Окружность

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег circle с присваиванием ему класса типа линии.

<circle class="line-type-1" cx="165" cy="25" r="125"/>

Эллипс

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег ellipse с присваиванием ему класса типа линии.

<ellipse class="line-type-3" cx="120" cy="280" rx="100" ry="50"/>

Дуга и дуга эллипса

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег path с присвоением ему класса типа линии. В свойстве d задаём параметры дуги.

<path class="line-type-2" d="M50,50 A140,140 0 0 1 200,350"/>	
<path class="line-type-3" d="M20,150 A20,40 0 0 1 130,50"/>

Прямоугольник

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег rect с присвоением ему класса типа линии.

<rect class="line-type-1" x="20" y="5" width="395" height="287"/>

Ломаная линия

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег polyline с присвоением ему класса типа линии.

<polyline class="line-type-7" points="20,250 50,250 60,300 80,120 120,140 200,180"/>

Кривая NURBS (сплайн)

Типы линий используем как и для тега line из CSS файла.
А в чертеже используем тег path с присвоением ему класса типа линии.

<path class="line-type-2" d="M140,201.34 C144.696,186.7859 152.303,175.3664 162.822,167.0820
    C167.996,163.0066 174.363,158.9944 180.459,157.132
    C194.3626,152.8843 213.0561,157.132 225.5589,167.082
    C232.5067,172.6114 241.8569,177.1221 250,177.9937
    C263.3438,179.4220 275.9399,163.2633 290.0,160
    C299.5142,157.7918 310.4253,154.6301 319.5409,157.132
    C325.7604,158.8390 332.0035,163.0066 337.1780,167.082
    C347.6966,175.3664 353.3294,189.206 360,201.3405"/>

Чертежи в SVG формате. Часть 1 — Черновик стандарта

2024-05-30T10:22:03.769Z

Мопед не мой, я только объявление разместил (с)

Это цикл статей, посвященных работе с SVG, размещенный на сайте http://v.sytnik.lviv.ua (ныне недоступный). Статьи мне показались очень информативными, поэтому захотелось их сохранить.

В интернете можно найти много разной информации о создании чертежей в формате SVG. Чаще предлагается какой-то редактор и экспорт из формата DXF в SVG. Просматривая код SVG сразу видно что там много лишнего. Созданный в одном редакторе файл SVG не всегда может корректно открыться в другом. Одно радует, что браузеры начали поддерживать SVG формат. Всюду пишут про недостатки использования SVG. А может надо придерживаться единых правил структуры файла для отображения чертежей?

Из экспериментов и тестов пришёл к таким правилам при создании чертёжа:

использование объектной модели чертежа;
используем только одну единицу измерения (та что по умолчанию в пикселях);
условно принимаем — один пиксель равен одному миллиметру (для браузера будет в пикселях, а для нас в мм);
масштаб описания элементов всегда 1:1;
для отображения объектов в другом масштабе используем вложенный svg рисунок;
для уникальных объектов задаём id а для характерных class;
…

Объектная модель чертежа

Упрощенно чертёж можно описать в виде XML структуры.

<svg id="Detail1" ...>
    <defs id="defsCAD"> ... </defs>
    <svg id="Shtamp" name="Frame drawing" ... >
        ...
    </svg>
    <svg id="View1" ... >
        <g id="layer-0" name="System layer" ...>
            <line class="line-type-1" ... />
            <line class="line-type-1" ... />
            <circle class="line-type-1" ... />
            <path class="line-type-1" ... />
            <rect class="line-type-1" ... />
            <line class="line-type-2" ... />
            <line class="line-type-2" ... />
            <g class="dimL">
                <line class="line-type-2" ... />
                <line class="line-type-2" ... />
                <line class="line-type-2" ... />
                <text ... >...</text> 
            </g>
            ...
        </g>
        <g id="layer-1" name="Layer 1" ...>
            ...
        </g>
    </svg>
    <svg id="View2" ... >
        <line class="line-type-1" ... />
        ...
    </svg>
    <svg id="View3" ... > ... </svg>
</svg>

Тег svg

<svg> — тег используется для описания самого чертежа и встроенных видов, штампа и техтребований. Если необходимо использовать масштаб отличный от 1:1, то реализуется с помощью свойств тега.
Например масштаб 1:4

<svg id="View1"
     x="50"
     y="7"
     width="150"
     height="162"
     viewBox="-25 -200 600 648">

width="150" height="162" viewBox="…… 600 648" — соотношение величин задаёт масштаб отображения вида на листе.

Например масштаб 10:1

<svg id="View1" 
     x="50" 
     y="7" 
     width="150" 
     height="162" 
     viewBox="-0.6 -5 15 16.2">

Тег defs

<defs> — здесь описываем все примитивные повторяющиеся элементы. Замечена одна особенность при использовании SVG элемента marker — на него не действуют параметры масштаба из тега <svg>, что намного упрощает работу с масштабом. (При любом масштабе вида стрелки в размерах должны быть одинаковые). Но на линии в элемента marker не действует параметр свойства vector-effect: non-scaling-stroke;

Тег line

<line class=«atr1» …/> — в файле CSS описываем стили линий для графических примитивов. Жаль что в Internet Explorer для каждого масштаба необходимо указывать свой стиль линии (толщина линии и интервал пунктиров). Как правило в чертеже одновременно не используются все возможные масштабы и достаточно задать только для используемых масштабов.
Пример описания стилей линий для элементов line, circle, path, rect и др.:

line, rect, circle, ellipse, path, text {
  vector-effect: non-scaling-stroke;
}
/* main line */
.line-type-1 { fill: none; stroke: blue; stroke-width: 2;
}
/* hairline */
.line-type-2 { fill: none; stroke: black; stroke-width: .7;
}
/* axial */
.line-type-3 { fill: none; stroke: red; stroke-width: .7; stroke-dasharray: 25, 4, 3, 4;
}
/* dashed */
.line-type-4 { fill: none; stroke: black; stroke-width: .7; stroke-dasharray: 7, 4;
}
/* main line for the scale 0.25 */
.line-type-1_025 { fill: none; stroke: blue; stroke-width: 8;
}
/* hairline for the scale 0.25 */
.line-type-2_025 { stroke: black; stroke-width: 2.8;
}

Тег g

<g class="dimL">…</g> — элементы описывающие объекты как размер группируем.
Пример:

...
<defs id="defsCAD">
<!-- Draw arrows and tick marks -->
    <marker id="dimArrow-1" viewBox="-2 -12 29 24" markerWidth="44" markerHeight="36" orient="auto">
        <path class="line-type-2_025" stroke="black" d="M0,0 L20,-4 16,0 20,4 z M0,-10 L0,10 M0,0 L27,0"/>
    </marker>
    <marker id="dimArrow-2" viewBox="-27 -12 29 24" markerWidth="44" markerHeight="36" orient="auto">
        <path class="line-type-2_025" stroke="black" d="M0,0 L-20,-4 -16,0 -20,4 z M0,-10 L0,10 M0,0 L-27,0"/>
    </marker>
</defs>
...
    <g class="DimL">
        <line class="line-type-2" x1="190" y1="180" x2="190" y2="230"/>
        <line class="line-type-2" x1="310" y1="180" x2="310" y2="230"/>
        <line id="dim1" class="line-type-2" x1="190" y1="230" x2="310" y2="230" marker-start="url(#dimArrow-1)" marker-end="url(#dimArrow-2)"/>
        <text x="265" y="222" font-size="28" text-anchor="middle">120</text> 
    </g>
...

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

<svg id="Shtamp" type="1" x="0" y="0" width="420" height="297" viewBox="0 0 420 297">
    ...
    <rect class="line-type-2" x="1" y="1" width="418" height="295"/>
   ....
</svg>

Дайте мне точку опоры...

2024-05-17T10:31:59.438Z

...и я переверну землю.

Котик переворачивает землю. ЯПлакал

Эту фразу приписывают Архимеду, так, во всяком случае, нам говорили в школе.

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

Координатная система SVG

Понадобилось мне сохранить векторный рисунок. Для этого SVG подходит как нельзя лучше — генерируется просто, размер небольшой, структура понятна и предсказуема.

Вот только незадача, координата Y в нем идет не так, как принято в математике — привычная нам ось идет вверх, тогда как в SVG — вниз. Пробуем рисовать. Будем использовать библиотеку cl-svg.

В Quicklisp устаревшая версия, поэтому имеет смысл склонировать ее себе в ~/quicklisp/local-projects/ и выполнить (ql:register-local-projects).

Итак, делаем простейший файл, рисуем координатные оси, ну или их какое-то подобие.

(in-package #:svg)

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230)
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)
  
  (draw scene (:line :x1   0 :y1 -10 :x2   0 :y2 200))
  
  (draw scene (:line :x1 -10 :y1   0 :x2 200 :y2   0)))

Запускаем, получился файл coord.svg. Запускаем его и... ничего.

Правильно, потому что по стандарту линия не рисуется, если у нее не задано значение цвета пера (stroke). Кроме того, у нас не задано значение поля viewPort.

Корректный вариант такой (далее первую форму (in-package #:svg) опускаю):

(with-svg-to-file
    (scene 'svg-1.1-toplevel
	   :height 230
	   :width 230
	   :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")
  
  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")
  
  (draw scene 
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green"))

Линии осей нарисованы зеленым цветом.

Для удобства восприятия добавлен прямоугольник под картинку.

Получилось что-то такое:

Как мы видим, ось Y растет вниз.

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

Попробуем другой метод.

Использование CSS

SVG позволяет использовать стилевую информацию. Этим мы и воспользуемся.

Добавим стиль, применяющий масштаб -1 к тегу <svg>:

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)
  
  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")
  
  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")
  
  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")
  
  (draw scene
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green"))

Идентификатор #toplevel создается внутри класса svg-1.1-toplevel.

Получилась замечательная картинка:

Прекрасно, давайте развивать решение. Добавим текста:

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")

  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")

  (draw scene
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green")

  (text scene (:x 20 :y 20) "Привет!"))

Ооочень интересно. Перевернут не только мир, но и текст.

Это забавно, но логично.

Хорошо, давайте теперь применим масштабирование и к тексту:

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (style scene "svg#toplevel > text {transform: scaleY(-1);}")

  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")

  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")

  (draw scene
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green")

  (text scene (:x 20 :y 20) "Привет!"))

Текст перевернулся, но теперь он расположен непонятно где:

Все дело в том, что преобразование scaleY(-1) выполняется относительно начала координат, а не относительно координат элемента, к которому это преобразование применяется. Получается, что базовая линия шрифта находится на координате Y, равной 20, и после применения масштабирования расположено также на 20 пикселей от оси, но в другую сторону.

Можно применить дополнительные преобразования — сначала перенести текст к началу координат, затем масштабировать, затем отнести снова назад. Но это нужно рассчитывать, давайте сделаем по-другому.

Обернем текст в группу и потом применим преобразование к тексту.

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (style scene "svg#toplevel g > text {transform: scaleY(-1);}")

  (draw scene
      (:rect :x -20 :y -20 :height 230 :width 230)
      :fill "#EEEEEE" :stroke "none")

  (draw scene
      (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")

  (draw scene
      (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green")

  (make-group scene
      (:transform "translate(20, 20)")
    (text*  (:x 0 :y 0) "Привет!")))

Получилось то, что нужно!

Ключевым здесь являются вызовы

(style scene "svg#toplevel g > text {transform: scaleY(-1);}")

...

(make-group scene
      (:transform "translate(20, 20)")
    (text*  (:x 0 :y 0) "Привет!"))

У тега <g> нет своих координат x и y, но к нему можно применить преобразование transform(), и в нем задать нужное смещение. Кроме того, координаты x и y для текста можно не указывать, но библиотека cl-svg требует, чтобы они были указаны, поэтому вписываем.

Вложенные группы

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

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (style scene "svg#toplevel g > text {transform: scaleY(-1);}")

  (make-group scene (:id "frame")
    (draw*
     (:rect :x -20 :y -20 :height 230 :width 230)
     :fill "#EEEEEE" :stroke "none"))

  (make-group scene (:id "axes")
    (draw*
     (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")
    (draw*
     (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green"))

  (let ((texts (make-group scene (:id "texts"))))
    (make-group texts (:transform "translate(20, 20)")
      (text*  (:x 0 :y 0) "Привет"))
    (make-group texts (:transform "translate(30, 40)")
      (text*  (:x 0 :y 0) "Мир"))
    (make-group texts (:transform "translate(30, 60) rotate(90)")
      (text*  (:x 0 :y 0) "SVG"))))

В последнем случае дополнительно текст повернут на 90 градусов, то есть можно производить больше одной трансформации или вообще задать матрицу преобразований.

Параметры viewPort

Последнее замечание сделаю относительно значений параметра viewPort тега <svg>.

Я долго не мог понять, как им пользоваться, пока не придумал такое объяснение.

Окно просмотра характеризуется двумя парами значений. Первая — положение окна просмотра в мировых (или пользовательских) координатах. По сути это просто точка на пользовательском чертеже.

Вторая пара задает количество точек на пользовательском чертеже, которые мы видим в окно просмотра, соответственно по горизонтали и вертикали, но при этом само окно имеет размер, задаваемый параметрами ширины и высоты тега <svg>.

То есть, viewPort имеет фиксированный размер на экране или в браузере, а вот содержимое его подстраивается с учетом коэффициентов, получаемых соотношением размеров из окна просмотра и тега <svg>. Кому как, а мне так стало понятнее.

UPD:

В библиотеке подумали о том, что иногда можно опустить проверку параметров:

(with-svg-to-file
    (scene 'svg-1.1-toplevel :height 230 :width 230 :view-box "-20 -20 230 230")
    (#p"~/devel/svg/coords.svg" :if-exists :supersede)

  (style scene "svg#toplevel {display:flex; transform: scaleY(-1);}")

  (style scene "svg#toplevel g > text {transform: scaleY(-1);}")

  (make-group scene (:id "frame")
    (draw*
     (:rect :x -20 :y -20 :height 230 :width 230)
     :fill "#EEEEEE" :stroke "none"))

  (make-group scene (:id "axes")
    (draw*
     (:line :x1 0 :y1 -10 :x2 0 :y2 200) :stroke "green")
    (draw*
     (:line :x1 -10 :y1 0 :x2 200 :y2 0) :stroke "green"))

  (without-attribute-check 
    (let ((texts (make-group scene (:id "texts"))))
      (make-group texts (:transform "translate(20, 20)")
	(text* () "Привет"))
      (make-group texts (:transform "translate(30, 40)")
	(text*  () "Мир"))
      (make-group texts (:transform "translate(30, 60) rotate(90)")
	(text* () "SVG")))))

см. (without-attribute-check ... )