Spring JDBC - это когда ты пишешь текст запроса, а оно потом из ResultSet-а значения через reflection запихивает в поля объекта. Spring Data JDBC - это когда ты даже запросы не пишешь, оно на основе названия метода сгенерирует запрос (и через reflection запихивает значения из ResultSet-а в поля объектов).
Ну начинается виляние, "структура", связи, длина, и прочий терминологический шум. В газе шарики? Шарики. У вас в стекле тоже шарики. Значит, по вашему выходит, что стекло - газ. В МКТ в стекле не шарики. Значит, ваша попытка покритиковать МКТ состоит в том, чтобы приписать ей то, что она не утверждает. С самого начала статьи, с закона сохранения импульса для шариков.
Ешё со школьных уроков «физики» мы знаем, что согласно «молекулярно-кинетической теории» (МКТ) молекулы газа похожи на абсолютно упругие бильярдные шары, которые с высокой скорость стукаются об стенки сосудов и отскакивают от них с той же скоростью
И после этого автор молекулы стекла тоже рассматривает как шары, то есть стекло - газ?
Я был неправ. В Postgres строка при обновлении действительно блокируется до тех пор, пока обновляющая транзакция не завершится. Postgres при обновлении помечает предыдущую версию строки как удалённую, прописывая в xmax номер транзакции, и создаёт новую версию строки, у которой xmin будет с номером следующей транзации. Новая версия помечается как ещё невидимая, потому что транзакция ещё активна. и этот же признак, что удалившая предыдущую версию строки транзакция ещё активна, является блокировкой строки.
Какая связь между незавершающейся программой и подсчётом ссылок? Ну сделал он в примере new до цикла, а в примере посложнее сделал бы в каком-нибудь методе, который вызывается в цикле и возвращает это значение. В C для этого возвращался бы указатель.
Динамическое выделение памяти не является непозволительной роскошью, реально используемой динамической памяти в каждый момент времени обычно сильно меньше, чем если бы память под все используемые данные была бы выделена статически.
И утечки тут не при чём, утечка - это когда память выделяется и не освобождается, в языках с динамической памятью и сборкой мусора нет явного освобождения, и если ссылок не осталось, то утечек не будет.
Да, в комментах не очень удобно форматировать текст. Спасибо за ответ. На основе этого я бы сказал, что та цитата из статьи, к которой я прицепился, содержит неверную информацию: на RTTI в ОЗУ тратится два байта.
Насчёт наследования классов - нифига, принципиальной разницы с наследованием интерфейсов нет.
Заодно новый вопрос: а вам сильно помогает хранить размер объекта в ОЗУ ? Он же одинаков для всех объектов одного класса, и его можно получать, обратившись по METADATA_ADDR. Я ещё могу понять массивы, но предполагаю, что длина массива у вас хранится явно и отдельно.
Я вот тоже хотел спросить, ntdll.dll - это, конечно, круто, но user32.dll, gdi32.dll, comctl32.dll, comdlg32.dll кто будет эмулировать? WINE это делает.
Я не сильно понял, что вы выиграли, отказавшись от наследования. С наследованием реализация была бы такой: у объекта есть указание на его класс, у класса таблица виртуальных функций. Вместо этого у вас каждый объект содержит поле-ссылку на родителя-делегата, по динамической памяти расход больше. Поэтому вот этот пассаж мне не ясен:
Компилятор берет всю тяжелую работу на себя и генерирует минимально необходимый RTTI (информация о типах во время выполнения), полностью упаковывая его в компактные метаданные во Flash-памяти. В ОЗУ под это не тратится ни одного байта.
Как это вы сделали, что у объекта нет информации о его классе?
Ещё хотел спросить: а что будет, если счётчик ссылок переполнится?
2) В Java объявить ещё один тип - это достаточно муторное занятие. Нужно создавать отдельный файл, ну и так далее. Но опыт показывает, что полезно создавать не мало больших типов, а много маленьких. А в Java это не удобно.
В Java публичный класс должен находиться в отдельном файле, а package-private и private классы не обязаны, могут жить в файле публичного класса, я часто это использую.
Я бы хотел, чтобы вы добавили возможность создавать типы в любом лексическом окружении. Это просто сделать, но это очень поможет программистам.
Java сто лет уже это умеет, вы можете объявлять классы внутри классов и внутри методов. Умеет ли язык автора - хз.
В организации, в которой я работаю, технологий много и процессы неоднородные.
В Firebird много хранимок, и они продолжают плодиться, а разработчики следуют такому процессу: для каждого релиза создаётся git-ветка, и туда добавляют меняющие скрипты. С хранимками и функциями проще, там всегда CREATE OR ALTER PROCEDURE, с таблицами - там ALTER TABLE, для данных тоже изменяющие скрипты. Отслеживать зависимости между этими сложно, разработчик должен это хорошо понимать. Если решили, что какой-то функционал нужно в следующий релиз подвинуть - это очень больно. Но зато сразу есть скрипты, которые будут менять прод базу в процессе релиза.
А разработчики, использующие Postgres, пошли по-другому: не пишут alter-скрипты, только создание базы с нуля. Структура такая: для каждой таблицы каталог, там скрипт создания таблицы, скрипт ограничений и скрипт грантов. Коллега написал инструмент на python, который сначала накатывает таблицы, потом ограничения, и в конце гранты. Это не один файл, как у вас, но хоть файлы, относящиеся к одной таблице, рядом лежат. У инструмента есть киллер-фича: он умеет, как ваш, создавать файлы из базы, а ещё умеет alter-скрипты создавать, имея старую базу и файлы для новой базы. В open source выложить не дадут, а жаль. Python для таких задач хорош, коллега, как вы, сначала пользовался isql/psql, но плюнул.
А насчёт того, как жить разработчику, который очень привык сначала экспериментировать с базой, а потом в git коммитить. Есть две вещи, которые могут помочь понять, что разработчик делал. Во-первых, можно писать историю запросов из инструментария. Вроде бы это умеет DBeaver Pro, возможно это умеет IBExpert. Во-вторых, можно в firebird на сервере настроить трассировку, и все запросы будут в файл попадать.
Процессы в вашей организации, конечно, грустные, git должен быть первичен, а база вторична. Но вообще такое, чтобы все на живой базе жили - не редкость.
Насчёт чтения метаданных в транзакции read commited не понял: чем snapshot не подошёл? Вроде бы можно читать, не блокируя никаких других читателей и писателей.
И ещё хотел спросить: из полученных скриптов можно создать новую базу? Если да, то как в этом случае определяется порядок накатки для таблиц, чтобы можно было foreigh key ограничения накатывать.
"А у меня будет свой Basic, c Питоном и Морским боем!". LIST вместо PRINT, ESLI вместо IF. В бейсике, помнится, переменные строкового типа имели $ в конце имени, а у автора, если я правильно догадался, имеют в начале.
Вот эти строки выглядят загадочно:
X[D]=X
Y[D]=Y
Я предполагаю, что X слева и X справа - это не одно и то же, X слева - это массив X-координат сегментов тела питона, а X справа - координата головы. Но вообще это путает.
Пафоса дофига. Гугл утверждает, что gcc давно считает, что исходники в UTF-8, и поддерживает другие кодировки, а значит юникод поддерживает без проблем. Добавляем в лексер синонимы для ключевых слов, и вроде всего делов, даже парсер трогать не надо.
Причина в том, что UPDATE в Postgres всегда берёт эксклюзивную блокировку строки на время транзакции — это встроенное поведение MVCC, а не наша логика. Конкурирующие записи в одну строку физически выстраиваются в очередь.
Что за чушь, нет в Postgres при простых обновлениях никаких блокировок строки, тупо появляются новые версии. Другое дело, что коммиты транзакций происходят последовательно, и та версия строки, которая соответствует транзакции, которая закоммичена последней, и будет видна следующим читателям. Или у вас serialized-транзакции?
Не совсем понял проблему. "Я хочу, чтобы все, кто инклудит вот этот файл, были бы обязаны вызвать вот такую функцию с каким-то своим аргументом". Зачем? Ваш файл содержит другие функции, которые будут вызваны. Нельзя ли сделать так, чтобы в первую вызываемую реально полезную функцию передавался этот аргумент?
Беседы с ИИ пересказывать, пожалуйста, не надо. И запятые, блин, научитесь их ставить!
Когда я дочитал то того места, в котором вы объясняете, что тайлы не успевают записаться за VBLANK, я хотел предложить копировать их построчно в процессе отрисовки кадра: копировать строку тайлов незадолго до того, как видеоконтроллер Sega начнёт отрисовывать соответствующие строки экрана. Но ваш вариант с отслеживанием обращений к видеопамяти ещё круче.
Я не очень понимаю проблему с распределением регистров при компиляции стековой виртуальной машины, в особенности апелляцию к одному проходу. Всё равно есть стадия проверки, что глубина стека совпадёт в точках выполнения, в которые можно прийти разными путями кода. Будем считать эту стадию нулевым проходом. На этой стадии у каждой инструкции проставляется глубина стека перед выполнением инструкции, это число и обозначает регистр, соответствующий вершине стека, каждый элемент ниже по стеку обозначается числом на единицу меньше.
Очень много водянистых слов.
Spring JDBC - это когда ты пишешь текст запроса, а оно потом из ResultSet-а значения через reflection запихивает в поля объекта. Spring Data JDBC - это когда ты даже запросы не пишешь, оно на основе названия метода сгенерирует запрос (и через reflection запихивает значения из ResultSet-а в поля объектов).
Ну начинается виляние, "структура", связи, длина, и прочий терминологический шум. В газе шарики? Шарики. У вас в стекле тоже шарики. Значит, по вашему выходит, что стекло - газ. В МКТ в стекле не шарики. Значит, ваша попытка покритиковать МКТ состоит в том, чтобы приписать ей то, что она не утверждает. С самого начала статьи, с закона сохранения импульса для шариков.
И после этого автор молекулы стекла тоже рассматривает как шары, то есть стекло - газ?
"Я стреляю не рукой. Тот, кто стреляет рукой, забыл лицо своего отца. Я стреляю разумом."
Я был неправ. В Postgres строка при обновлении действительно блокируется до тех пор, пока обновляющая транзакция не завершится. Postgres при обновлении помечает предыдущую версию строки как удалённую, прописывая в xmax номер транзакции, и создаёт новую версию строки, у которой xmin будет с номером следующей транзации. Новая версия помечается как ещё невидимая, потому что транзакция ещё активна. и этот же признак, что удалившая предыдущую версию строки транзакция ещё активна, является блокировкой строки.
Какая связь между незавершающейся программой и подсчётом ссылок? Ну сделал он в примере new до цикла, а в примере посложнее сделал бы в каком-нибудь методе, который вызывается в цикле и возвращает это значение. В C для этого возвращался бы указатель.
Динамическое выделение памяти не является непозволительной роскошью, реально используемой динамической памяти в каждый момент времени обычно сильно меньше, чем если бы память под все используемые данные была бы выделена статически.
И утечки тут не при чём, утечка - это когда память выделяется и не освобождается, в языках с динамической памятью и сборкой мусора нет явного освобождения, и если ссылок не осталось, то утечек не будет.
Да, в комментах не очень удобно форматировать текст. Спасибо за ответ. На основе этого я бы сказал, что та цитата из статьи, к которой я прицепился, содержит неверную информацию: на RTTI в ОЗУ тратится два байта.
Насчёт наследования классов - нифига, принципиальной разницы с наследованием интерфейсов нет.
Заодно новый вопрос: а вам сильно помогает хранить размер объекта в ОЗУ ? Он же одинаков для всех объектов одного класса, и его можно получать, обратившись по METADATA_ADDR. Я ещё могу понять массивы, но предполагаю, что длина массива у вас хранится явно и отдельно.
Я вот тоже хотел спросить, ntdll.dll - это, конечно, круто, но user32.dll, gdi32.dll, comctl32.dll, comdlg32.dll кто будет эмулировать? WINE это делает.
Я не сильно понял, что вы выиграли, отказавшись от наследования. С наследованием реализация была бы такой: у объекта есть указание на его класс, у класса таблица виртуальных функций. Вместо этого у вас каждый объект содержит поле-ссылку на родителя-делегата, по динамической памяти расход больше. Поэтому вот этот пассаж мне не ясен:
Как это вы сделали, что у объекта нет информации о его классе?
Ещё хотел спросить: а что будет, если счётчик ссылок переполнится?
В Java публичный класс должен находиться в отдельном файле, а package-private и private классы не обязаны, могут жить в файле публичного класса, я часто это использую.
Java сто лет уже это умеет, вы можете объявлять классы внутри классов и внутри методов. Умеет ли язык автора - хз.
В организации, в которой я работаю, технологий много и процессы неоднородные.
В Firebird много хранимок, и они продолжают плодиться, а разработчики следуют такому процессу: для каждого релиза создаётся git-ветка, и туда добавляют меняющие скрипты. С хранимками и функциями проще, там всегда CREATE OR ALTER PROCEDURE, с таблицами - там ALTER TABLE, для данных тоже изменяющие скрипты. Отслеживать зависимости между этими сложно, разработчик должен это хорошо понимать. Если решили, что какой-то функционал нужно в следующий релиз подвинуть - это очень больно. Но зато сразу есть скрипты, которые будут менять прод базу в процессе релиза.
А разработчики, использующие Postgres, пошли по-другому: не пишут alter-скрипты, только создание базы с нуля. Структура такая: для каждой таблицы каталог, там скрипт создания таблицы, скрипт ограничений и скрипт грантов. Коллега написал инструмент на python, который сначала накатывает таблицы, потом ограничения, и в конце гранты. Это не один файл, как у вас, но хоть файлы, относящиеся к одной таблице, рядом лежат. У инструмента есть киллер-фича: он умеет, как ваш, создавать файлы из базы, а ещё умеет alter-скрипты создавать, имея старую базу и файлы для новой базы. В open source выложить не дадут, а жаль. Python для таких задач хорош, коллега, как вы, сначала пользовался isql/psql, но плюнул.
А насчёт того, как жить разработчику, который очень привык сначала экспериментировать с базой, а потом в git коммитить. Есть две вещи, которые могут помочь понять, что разработчик делал. Во-первых, можно писать историю запросов из инструментария. Вроде бы это умеет DBeaver Pro, возможно это умеет IBExpert. Во-вторых, можно в firebird на сервере настроить трассировку, и все запросы будут в файл попадать.
Очень неплохо.
Процессы в вашей организации, конечно, грустные, git должен быть первичен, а база вторична. Но вообще такое, чтобы все на живой базе жили - не редкость.
Насчёт чтения метаданных в транзакции read commited не понял: чем snapshot не подошёл? Вроде бы можно читать, не блокируя никаких других читателей и писателей.
И ещё хотел спросить: из полученных скриптов можно создать новую базу? Если да, то как в этом случае определяется порядок накатки для таблиц, чтобы можно было foreigh key ограничения накатывать.
"А у меня будет свой Basic, c Питоном и Морским боем!". LIST вместо PRINT, ESLI вместо IF. В бейсике, помнится, переменные строкового типа имели $ в конце имени, а у автора, если я правильно догадался, имеют в начале.
Вот эти строки выглядят загадочно:
Я предполагаю, что X слева и X справа - это не одно и то же, X слева - это массив X-координат сегментов тела питона, а X справа - координата головы. Но вообще это путает.
Пафоса дофига. Гугл утверждает, что gcc давно считает, что исходники в UTF-8, и поддерживает другие кодировки, а значит юникод поддерживает без проблем. Добавляем в лексер синонимы для ключевых слов, и вроде всего делов, даже парсер трогать не надо.
Что за чушь, нет в Postgres при простых обновлениях никаких блокировок строки, тупо появляются новые версии. Другое дело, что коммиты транзакций происходят последовательно, и та версия строки, которая соответствует транзакции, которая закоммичена последней, и будет видна следующим читателям. Или у вас serialized-транзакции?
Дожили, даже хнык-статью без нейронки написать не могут.
Не совсем понял проблему. "Я хочу, чтобы все, кто инклудит вот этот файл, были бы обязаны вызвать вот такую функцию с каким-то своим аргументом". Зачем? Ваш файл содержит другие функции, которые будут вызваны. Нельзя ли сделать так, чтобы в первую вызываемую реально полезную функцию передавался этот аргумент?
Беседы с ИИ пересказывать, пожалуйста, не надо. И запятые, блин, научитесь их ставить!
Когда я дочитал то того места, в котором вы объясняете, что тайлы не успевают записаться за VBLANK, я хотел предложить копировать их построчно в процессе отрисовки кадра: копировать строку тайлов незадолго до того, как видеоконтроллер Sega начнёт отрисовывать соответствующие строки экрана. Но ваш вариант с отслеживанием обращений к видеопамяти ещё круче.
Не совсем понял, что вы имеете в виду. Чем WebAssembly в этом плане отличается от компиляции в код любой виртуальной или реальной машины?
Я не очень понимаю проблему с распределением регистров при компиляции стековой виртуальной машины, в особенности апелляцию к одному проходу. Всё равно есть стадия проверки, что глубина стека совпадёт в точках выполнения, в которые можно прийти разными путями кода. Будем считать эту стадию нулевым проходом. На этой стадии у каждой инструкции проставляется глубина стека перед выполнением инструкции, это число и обозначает регистр, соответствующий вершине стека, каждый элемент ниже по стеку обозначается числом на единицу меньше.