Пафоса дофига. Гугл утверждает, что gcc давно считает, что исходники в UTF-8, и поддерживает другие кодировки, а значит юникод поддерживает без проблем. Добавляем в лексер синонимы для ключевых слов, и вроде всего делов, даже парсер трогать не надо.
Причина в том, что UPDATE в Postgres всегда берёт эксклюзивную блокировку строки на время транзакции — это встроенное поведение MVCC, а не наша логика. Конкурирующие записи в одну строку физически выстраиваются в очередь.
Что за чушь, нет в Postgres при простых обновлениях никаких блокировок строки, тупо появляются новые версии. Другое дело, что коммиты транзакций происходят последовательно, и та версия строки, которая соответствует транзакции, которая закоммичена последней, и будет видна следующим читателям. Или у вас serialized-транзакции?
Не совсем понял проблему. "Я хочу, чтобы все, кто инклудит вот этот файл, были бы обязаны вызвать вот такую функцию с каким-то своим аргументом". Зачем? Ваш файл содержит другие функции, которые будут вызваны. Нельзя ли сделать так, чтобы в первую вызываемую реально полезную функцию передавался этот аргумент?
Беседы с ИИ пересказывать, пожалуйста, не надо. И запятые, блин, научитесь их ставить!
Когда я дочитал то того места, в котором вы объясняете, что тайлы не успевают записаться за VBLANK, я хотел предложить копировать их построчно в процессе отрисовки кадра: копировать строку тайлов незадолго до того, как видеоконтроллер Sega начнёт отрисовывать соответствующие строки экрана. Но ваш вариант с отслеживанием обращений к видеопамяти ещё круче.
Я не очень понимаю проблему с распределением регистров при компиляции стековой виртуальной машины, в особенности апелляцию к одному проходу. Всё равно есть стадия проверки, что глубина стека совпадёт в точках выполнения, в которые можно прийти разными путями кода. Будем считать эту стадию нулевым проходом. На этой стадии у каждой инструкции проставляется глубина стека перед выполнением инструкции, это число и обозначает регистр, соответствующий вершине стека, каждый элемент ниже по стеку обозначается числом на единицу меньше.
Elixir анализирует поток выполнения программы и постепенно уточняет тип переменной по мере того, как она используется. Например, если вы написали условную конструкцию if is_integer(value), то внутри ветки true компилятор будет считать, что value имеет тип integer(), а не dynamic(). Ветка false получит противоположный вывод.
Интересно, как это работает. if ожидает булевское выражение. Там проверяется, что выражение - вызов функции с именем is_integer() ?
То, какой инстанс тайпкласса будет использоваться в каждом конкретном вызове, известно на этапе компиляции. Передача словаря - это деталь реализации, вполне можно было бы вместо словаря генерировать мономорфные реализации функции для каждого инстанса, наподобие того, как в C++ генерируются экземпляры шаблонных функций
На Java, C# и Python обёртки вокруг C-шных функций из Win32 API будут выглядеть примерно так же. Красота самих обёрточных функций никого не волнует. Зато Rust-функция принимает на один параметр меньше.
Это не то чтобы однозначно хорошая идея: если видеопамять хранит bitmap-ы, то её нужно сильно больше, чем видеопамяти под символы. А если сравнить цены на RAM между 1973 и 1982 годами...
Насчёт того, кто придумал: у ZX80 и ZX81 видеосигнал формировал сам Z80, читал коды символов из экранного буфера и превращал их в пиксели для горизонтальной развёртки. Очень дешёвый вариант: компактное хранение и мало микросхем. В ZX Spectrum уже ULA отслеживала номер линии, формировала видео-адрес, читала байт и отдавала пиксели, там не сильно сложно, сдвиговый регистр.
Вроде бы с первой версии, а это уже 30 лет. 30 лет, в dotnet люди могут плюс-минус эффективно управлять памятью. И вопрос был именно про это.. как так получилось, что в java настолько консервативная, что это не завезли за долгие годы
Не было запроса.
Далеко не факт, что многократное копирование эффективнее, чем копирование ссылок
Всё равно есть скалярные типы, и для длительного хранения больших списков целых чисел очень быстро написали либы с коллекциями скаляров, так боролись с футпринтом.
А помимо бокс-классов для скаляров не так уж и много value-типов в стандартной библиотеке. String, например, не будет value-типом, он и в C# таковым не является, при этом он часто хранится в коллекциях.
Пока не будет изменения в generic-ах, значимость value-типов сильно преувеличена.
Я немного почитал про C#, и сравнительная история выглядит так: в старых версиях и Java, и C# списки были сделаны как обёртки над массивом Object-ов, потому что он является общим предком объектов. При этом value types, чтобы их поместить в такой массив, боксятся. Как я понимаю, на каждый value type генерируется бокс-класс. Так что на уровне хранения в коллекциях память использовалась примерно одинаково. Потом в C# добавили generic-и, и для них сделали новые классы коллекций, там на каждый тип элемента для списков можно использовать массив подходящего типа и избежать боксинга. А в Java при добавлении generic-ов решили не ломать совместимость и не плодить коллекций, а раз уж всё равно боксить, то нафиг value types?
мы можем передавать value types как по значениюvoid Foo(MyStruct arg), а можем по ссылке void Foo(ref MyStruct arg)
Это не совсем struct. Насколько я знаю, struct не аллоцируются на куче, а в кадре стека или инлайнятся в массивы/классы и всегда копируются. Для value-классов то, где оно будет аллоцироваться, будет решать jit-компилятор, вполне возможно, что он будет аллоцирован на куче, ссылка передаваться из кадра в кадр, а при сохранении в массив произойдёт копирование полей.
Чёрт, а я думал, что опыт показал, что если хорошо работать и делать качественные продукты с высокой добавленной стоимостью, тогда можно без проблем купить нужное для изготовления сырьё. Спасибо, что раскрыли мне глаза!
Как убедительно показал опыт большевиков, подлинное развитие любой стратегической отрасли начинается с создания собственной сырьевой и технологической базы: без этого любые амбициозные планы неизбежно остаются на бумаге.
А что убедительно показал опыт Японии, Южной Кореи и Тайваня?
Про разницу между "интерактивным интерпретатором" и "переписывание работающей программы" я оставлю на совести комментатора, который это ляпнул. Но для повышения всеобщего уровня грамотности на ваш вопрос отвечу.
В C определение функции с именем f означает, что компилятор в пространстве кода сформирует код и символ f, который указывает на этот код и значение которого поменять нельзя. А в Scheme объявление (define f (lambda (x) (+ x 2))) означает, что глобальная переменная f имеет значение-функцию. При вызове функции через имя f, например, так (f 3), будет взято текущее значение этой переменной, а именно значение-функция, определённая лямбдой, и выполнена для переданного аргумента. Значение глобальной переменной можно поменять, и f может начать ссылаться на другую функцию. Когда к f обратятся в следующий раз, то там будет новое значение, но если код из f выполнялся на момент изменения, то он продолжит выполнение до выхода из функции.
REPL - это такое особое Lisp-приложение, в котором поток исполнения в бесконечном цикле читает ввод пользователя, парсит его, выполняет eval для динамического выполнения кода и печатает результат. Поэтому хоть в REPL, хоть не в нём можно поменять значение глобальной переменной с одной функции на другую, пропатчив код. Не у всякого рабочего Lisp-приложения это возможно, обычно для этого приложение, помимо основных рабочих потоков, должно специально оставить REPL-поток, через который можно подключиться и это сделать.
Какой запрос на генерацию Forth-кода, мужик, ты о чём? Весь сгенерированный LLM-код нужно очень внимательно ревьюить, а ревьюить Forth-код - это такая адская боль, нужно его в голове интерпретировать, удерживая в своей памяти содержимое стека.
Пафоса дофига. Гугл утверждает, что gcc давно считает, что исходники в UTF-8, и поддерживает другие кодировки, а значит юникод поддерживает без проблем. Добавляем в лексер синонимы для ключевых слов, и вроде всего делов, даже парсер трогать не надо.
Что за чушь, нет в Postgres при простых обновлениях никаких блокировок строки, тупо появляются новые версии. Другое дело, что коммиты транзакций происходят последовательно, и та версия строки, которая соответствует транзакции, которая закоммичена последней, и будет видна следующим читателям. Или у вас serialized-транзакции?
Дожили, даже хнык-статью без нейронки написать не могут.
Не совсем понял проблему. "Я хочу, чтобы все, кто инклудит вот этот файл, были бы обязаны вызвать вот такую функцию с каким-то своим аргументом". Зачем? Ваш файл содержит другие функции, которые будут вызваны. Нельзя ли сделать так, чтобы в первую вызываемую реально полезную функцию передавался этот аргумент?
Беседы с ИИ пересказывать, пожалуйста, не надо. И запятые, блин, научитесь их ставить!
Когда я дочитал то того места, в котором вы объясняете, что тайлы не успевают записаться за VBLANK, я хотел предложить копировать их построчно в процессе отрисовки кадра: копировать строку тайлов незадолго до того, как видеоконтроллер Sega начнёт отрисовывать соответствующие строки экрана. Но ваш вариант с отслеживанием обращений к видеопамяти ещё круче.
Не совсем понял, что вы имеете в виду. Чем WebAssembly в этом плане отличается от компиляции в код любой виртуальной или реальной машины?
Я не очень понимаю проблему с распределением регистров при компиляции стековой виртуальной машины, в особенности апелляцию к одному проходу. Всё равно есть стадия проверки, что глубина стека совпадёт в точках выполнения, в которые можно прийти разными путями кода. Будем считать эту стадию нулевым проходом. На этой стадии у каждой инструкции проставляется глубина стека перед выполнением инструкции, это число и обозначает регистр, соответствующий вершине стека, каждый элемент ниже по стеку обозначается числом на единицу меньше.
Интересно, как это работает. if ожидает булевское выражение. Там проверяется, что выражение - вызов функции с именем is_integer() ?
Слишком лирическая статья получилась.
То, какой инстанс тайпкласса будет использоваться в каждом конкретном вызове, известно на этапе компиляции. Передача словаря - это деталь реализации, вполне можно было бы вместо словаря генерировать мономорфные реализации функции для каждого инстанса, наподобие того, как в C++ генерируются экземпляры шаблонных функций
Но вам нужно уметь понимать этот зоопарк, если вы хотите читать код коллег или исходники библиотек.
На Java, C# и Python обёртки вокруг C-шных функций из Win32 API будут выглядеть примерно так же. Красота самих обёрточных функций никого не волнует. Зато Rust-функция принимает на один параметр меньше.
Это не то чтобы однозначно хорошая идея: если видеопамять хранит bitmap-ы, то её нужно сильно больше, чем видеопамяти под символы. А если сравнить цены на RAM между 1973 и 1982 годами...
Насчёт того, кто придумал: у ZX80 и ZX81 видеосигнал формировал сам Z80, читал коды символов из экранного буфера и превращал их в пиксели для горизонтальной развёртки. Очень дешёвый вариант: компактное хранение и мало микросхем. В ZX Spectrum уже ULA отслеживала номер линии, формировала видео-адрес, читала байт и отдавала пиксели, там не сильно сложно, сдвиговый регистр.
Не было запроса.
Далеко не факт, что многократное копирование эффективнее, чем копирование ссылок
Всё равно есть скалярные типы, и для длительного хранения больших списков целых чисел очень быстро написали либы с коллекциями скаляров, так боролись с футпринтом.
А помимо бокс-классов для скаляров не так уж и много value-типов в стандартной библиотеке. String, например, не будет value-типом, он и в C# таковым не является, при этом он часто хранится в коллекциях.
Пока не будет изменения в generic-ах, значимость value-типов сильно преувеличена.
Я немного почитал про C#, и сравнительная история выглядит так: в старых версиях и Java, и C# списки были сделаны как обёртки над массивом Object-ов, потому что он является общим предком объектов. При этом value types, чтобы их поместить в такой массив, боксятся. Как я понимаю, на каждый value type генерируется бокс-класс. Так что на уровне хранения в коллекциях память использовалась примерно одинаково. Потом в C# добавили generic-и, и для них сделали новые классы коллекций, там на каждый тип элемента для списков можно использовать массив подходящего типа и избежать боксинга. А в Java при добавлении generic-ов решили не ломать совместимость и не плодить коллекций, а раз уж всё равно боксить, то нафиг value types?
выглядит как чисто performance hint.
Это не совсем struct. Насколько я знаю, struct не аллоцируются на куче, а в кадре стека или инлайнятся в массивы/классы и всегда копируются. Для value-классов то, где оно будет аллоцироваться, будет решать jit-компилятор, вполне возможно, что он будет аллоцирован на куче, ссылка передаваться из кадра в кадр, а при сохранении в массив произойдёт копирование полей.
Чёрт, а я думал, что опыт показал, что если хорошо работать и делать качественные продукты с высокой добавленной стоимостью, тогда можно без проблем купить нужное для изготовления сырьё. Спасибо, что раскрыли мне глаза!
А что убедительно показал опыт Японии, Южной Кореи и Тайваня?
Про разницу между "интерактивным интерпретатором" и "переписывание работающей программы" я оставлю на совести комментатора, который это ляпнул. Но для повышения всеобщего уровня грамотности на ваш вопрос отвечу.
В C определение функции с именем f означает, что компилятор в пространстве кода сформирует код и символ f, который указывает на этот код и значение которого поменять нельзя. А в Scheme объявление (define f (lambda (x) (+ x 2))) означает, что глобальная переменная f имеет значение-функцию. При вызове функции через имя f, например, так (f 3), будет взято текущее значение этой переменной, а именно значение-функция, определённая лямбдой, и выполнена для переданного аргумента. Значение глобальной переменной можно поменять, и f может начать ссылаться на другую функцию. Когда к f обратятся в следующий раз, то там будет новое значение, но если код из f выполнялся на момент изменения, то он продолжит выполнение до выхода из функции.
REPL - это такое особое Lisp-приложение, в котором поток исполнения в бесконечном цикле читает ввод пользователя, парсит его, выполняет eval для динамического выполнения кода и печатает результат. Поэтому хоть в REPL, хоть не в нём можно поменять значение глобальной переменной с одной функции на другую, пропатчив код. Не у всякого рабочего Lisp-приложения это возможно, обычно для этого приложение, помимо основных рабочих потоков, должно специально оставить REPL-поток, через который можно подключиться и это сделать.
Какой запрос на генерацию Forth-кода, мужик, ты о чём? Весь сгенерированный LLM-код нужно очень внимательно ревьюить, а ревьюить Forth-код - это такая адская боль, нужно его в голове интерпретировать, удерживая в своей памяти содержимое стека.