История изменений

Ладно, давай мы предположим на секунду, что у тебя длиннее. Хотя я, например, исправил https://bugs.launchpad.net/sbcl/ bug/1733622, которая идёт со времён CMU. Stassats сказал, что я там что-то «изуродовал» и патч мой не был принят, но я к этому всерьёз не отношусь, т.к. давно наблюдаю процесс поддержки SBCL. Во всяком случае, SBCL собирается, штатная тест-сюита проходят и бага не проявляется. Помимо этого, я сумел кое-как добавить иммутабельные хеш-таблицы в SBCL. Это тоже никому не нужно (в лиспе же всего хватает, да). Но мой форк умел ругатся во время компиляции при попытке осуществить запись в иммутабельную хеш-таблицу. При этом иммутабельная хеш-таблица имеет тип (and hash-table (mutable 0)), а мутабельная - (and hash-table (mutable 1)), соответственно, вывод типов может рассуждать о мутабельности. Что он не умел - так это корректно обрабатывать момент вызова freeze-object, при котором иммутабельная таблица превращается в мутабельную, поскольку в этом месте происходит небывалое - тип объекта меняется. Система вывода типов SBCL не заточена на такое, именно поэтому возникла та бага. Она наивно полагает, что (cons integer) всегда таковым и останется, и делает оптимизации (которые нельзя отключить, кстати) на базе этой информации. В этом и состоит смысл упомянутой баги. Чтобы решить вопрос с freeze-type, пришлось, бы по сути, перерабатывать вывод типов. Чтобы понять, как он сейчас работает, я решил вооружиться степпером, который в SBCL тоже хронически не работает. Я довольно много поправил в степпере и тут окончательно осознал, что SBCL вообще низкокачественный и что в нём придётся чинить не только вывод типов, а ещё и всё остальное, что команда ничего делать не будет (а на самом деле я могу только реализовать концепт, для доведения до настоящего качества моей квалификации не хватает, нужна помощь команды, а они меня послали) и что мне всё это в сумме на данный момент не потянуть.

Предположим, что ты более меняя преуспел в изучении начинки SBCL (который, кстати, не полностью соблюдает стандарт CL в плане declare и the).

Проблема в том, что слово lattice я не слышал со времён алгебры на мехмате. Поэтому, естественно, я не знаю, что в SBCL не lattice. Я сейчас посмотрел, что такое lattice и из определений я не смог заключить, каким образом в Дельфи Lattice. Но из этого отнюдь не следует, что я не понимаю SBCL - иначе я не смог бы сделать то, что я сделал.

То есть, я считаю, что я достаточно точно понимаю, что есть в системе типов (и в системе контроля типов, если тебе так угодно) CL, SBCL, что из этого мне годится, а чего не хватает.

И вот тут приходишь ты и говоришь, что я не понимаю. Давай, говори, что я конкретно не понимаю. Или это будет просто выглядеть как некий наброс на вентилятор (клевета). Впрочем, я на 95% уверен, что это оно и есть, но оставшиеся 5% стоят того, чтобы вот это написать.

Далее, то, что ты пишешь про оптимизации - в корне неверно. Либо какая-то система ставит целью быть high performance - тогда она должна ревностно относиться к любым случаям, когда другая система быстрее, добиваться своего преимущества и доказывать его. SBCL декларируется как high performance, и исключительно поэтому я обратил на него своё внимание. Если бы мне не нужно было performance, я бы уже давно его забыл как страшный сон.

В этом случае «я переписал с С++ на .net и наверняка на лиспе было бы не медленнее» совершенно никуда не годится как обоснование.

Если же система позиционируется как «пригодная для ваших целей», то тогда да, защитник этой системы имеет право спрашивать ботлнеки. Т.е. непонятно, почему я тебе должен что-то предъявлять - мне нужно high performance и SBCL декларируется как high performance. Знаешь ты это или нет, и как ты это не назови, но его performance базируется на выводе типов, на отсечении в рантайме истинных и ложных ветвей, на подстановке специализированных тел функций в зависимости от известных в статике типов аргументов, на вычислениях во время компиляции, на исключении динамических проверок типов, если соответствие типов доказано статически (и для этого вовсе не нужно safety 0). В этом контексте достаточно сказать «неустранимая проверка типов в рантайме», «невозмодно сделать inline из-за отсутствия информации о типах» и все всё сразу поймут. Ты не понимаешь - это вопрос к твоей квалификации, не к моей. Кроме того, предъявлять тебе всё равно нет смысла, поскольку даже свой CLR ты последний раз выкладывал 2 года назад, и практическая польза от тебя строго равна нулю. А я свой последний коммит лиспового кода сделал сегодня. Если я предъявлю, ты всё равно это не сможешь исправить. Я, например, точно знаю, что я могу в сжатые сроки (за несколько дней) сделать более быстрые типизированные хеш-таблицы для SBCL. Но не буду. Для CCL может быть и сделаю когда-нибудь.

Ладно, давай мы предположим на секунду, что у тебя длиннее. Хотя я, например, исправил https://bugs.launchpad.net/sbcl/ bug/1733622, которая идёт со времён CMU. Stassats сказал, что я там что-то «изуродовал» и патч мой не был принят, но я к этому всерьёз не отношусь, т.к. давно наблюдаю процесс поддержки SBCL. Во всяком случае, SBCL собирается, штатная тест-сюита проходят и бага не проявляется. Помимо этого, я сумел кое-как добавить иммутабельные хеш-таблицы в SBCL. Это тоже никому не нужно (в лиспе же всего хватает, да). Но мой форк умел ругатся во время компиляции при попытке осуществить запись в иммутабельную структуру. Что он не умел - так это корректно обрабатывать момент вызова freeze-object, при котором иммутабельная таблица превращается в мутабельную, поскольку в этом месте происходит небывалое - тип объекта меняется. Система вывода типов SBCL не заточена на такое, именно поэтому возникла та бага. Она наивно полагает, что (cons integer) всегда таковым и останется, и делает оптимизации (которые нельзя отключить, кстати) на базе этой информации. В этом и состоит смысл упомянутой баги. Чтобы решить вопрос с freeze-type, пришлось, бы по сути, перерабатывать вывод типов. Чтобы понять, как он сейчас работает, я решил вооружиться степпером, который в SBCL тоже хронически не работает. Я довольно много поправил в степпере и тут окончательно осознал, что SBCL вообще низкокачественный и что в нём придётся чинить не только вывод типов, а ещё и всё остальное, что команда ничего делать не будет (а на самом деле я могу только реализовать концепт, для доведения до настоящего качества моей квалификации не хватает, нужна помощь команды, а они меня послали) и что мне всё это в сумме на данный момент не потянуть.

Предположим, что ты более меняя преуспел в изучении начинки SBCL (который, кстати, не полностью соблюдает стандарт CL в плане declare и the).

Проблема в том, что слово lattice я не слышал со времён алгебры на мехмате. Поэтому, естественно, я не знаю, что в SBCL не lattice. Я сейчас посмотрел, что такое lattice и из определений я не смог заключить, каким образом в Дельфи Lattice. Но из этого отнюдь не следует, что я не понимаю SBCL - иначе я не смог бы сделать то, что я сделал.

То есть, я считаю, что я достаточно точно понимаю, что есть в системе типов (и в системе контроля типов, если тебе так угодно) CL, SBCL, что из этого мне годится, а чего не хватает.

И вот тут приходишь ты и говоришь, что я не понимаю. Давай, говори, что я конкретно не понимаю. Или это будет просто выглядеть как некий наброс на вентилятор (клевета). Впрочем, я на 95% уверен, что это оно и есть, но оставшиеся 5% стоят того, чтобы вот это написать.

Далее, то, что ты пишешь про оптимизации - в корне неверно. Либо какая-то система ставит целью быть high performance - тогда она должна ревностно относиться к любым случаям, когда другая система быстрее, добиваться своего преимущества и доказывать его. SBCL декларируется как high performance, и исключительно поэтому я обратил на него своё внимание. Если бы мне не нужно было performance, я бы уже давно его забыл как страшный сон.

В этом случае «я переписал с С++ на .net и наверняка на лиспе было бы не медленнее» совершенно никуда не годится как обоснование.

Если же система позиционируется как «пригодная для ваших целей», то тогда да, защитник этой системы имеет право спрашивать ботлнеки. Т.е. непонятно, почему я тебе должен что-то предъявлять - мне нужно high performance и SBCL декларируется как high performance. Знаешь ты это или нет, и как ты это не назови, но его performance базируется на выводе типов, на отсечении в рантайме истинных и ложных ветвей, на подстановке специализированных тел функций в зависимости от известных в статике типов аргументов, на вычислениях во время компиляции, на исключении динамических проверок типов, если соответствие типов доказано статически (и для этого вовсе не нужно safety 0). В этом контексте достаточно сказать «неустранимая проверка типов в рантайме», «невозмодно сделать inline из-за отсутствия информации о типах» и все всё сразу поймут. Ты не понимаешь - это вопрос к твоей квалификации, не к моей. Кроме того, предъявлять тебе всё равно нет смысла, поскольку даже свой CLR ты последний раз выкладывал 2 года назад, и практическая польза от тебя строго равна нулю. А я свой последний коммит лиспового кода сделал сегодня. Если я предъявлю, ты всё равно это не сможешь исправить. Я, например, точно знаю, что я могу в сжатые сроки (за несколько дней) сделать более быстрые типизированные хеш-таблицы для SBCL. Но не буду. Для CCL может быть и сделаю когда-нибудь.

Ладно, давай мы предположим на секунду, что у тебя длиннее. Хотя я, например, исправил https://bugs.launchpad.net/sbcl/ bug/1733622, которая идёт со времён CMU. Stassats сказал, что я там что-то «изуродовал» и патч мой не был принят, но я к этому всерьёз не отношусь, т.к. давно наблюдаю процесс поддержки SBCL. Во всяком случае, SBCL собирается, штатная тест-сюита проходят и бага не проявляется. Помимо этого, я сумел кое-как добавить иммутабельные хеш-таблицы в SBCL. Это тоже никому не нужно (в лиспе же всего хватает, да). Но мой форк умел ругатся во время компиляции при попытке осуществить запись в иммутабельную структуру. Что он не умел - так это корректно обрабатывать момент вызова freeze-object, при котором иммутабельная таблица превращается в мутабельную, поскольку в этом месте происходит небывалое - тип объекта меняется. Система вывода типов SBCL не заточена на такое, именно поэтому возникла та бага. Она наивно полагает, что (cons integer) всегда таковым и останется, и делает оптимизации (которые нельзя отключить, кстати) на базе этой информации. В этом и состоит смысл упомянутой баги. Чтобы решить вопрос с freeze-type, пришлось, бы по сути, перерабатывать вывод типов. Чтобы понять, как он сейчас работает, я решил вооружиться степпером, который в SBCL тоже хронически не работает. Я довольно много поправил в степпере и тут окончательно осознал, что SBCL вообще низкокачественный и что в нём придётся чинить не только вывод типов, а ещё и всё остальное, что команда ничего делать не будет (а на самом деле я могу только реализовать концепт, для доведения до настоящего качества моей квалификации не хватает, нужна помощь команды, а они меня послали) и что мне всё это в сумме на данный момент не потянуть.

Предположим, что ты более меняя преуспел в изучении начинки SBCL (который, кстати, не полностью соблюдает стандарт CL в плане declare и the).

Проблема в том, что слово lattice я не слышал со времён алгебры на мехмате. Поэтому, естественно, я не знаю, что в SBCL не lattice. Я сейчас посмотрел, что такое lattice и из определений я не смог заключить, каким образом в Дельфи Lattice. Но из этого отнюдь не следует, что я не понимаю SBCL - иначе я не смог бы сделать то, что я сделал.

То есть, я считаю, что я достаточно точно понимаю, что есть в системе типов (и в системе контроля типов, если тебе так угодно) CL, SBCL, что из этого мне годится, а чего не хватает.

И вот тут приходишь ты и говоришь, что я не понимаю. Давай, говори, что я конкретно не понимаю. Или это будет просто выглядеть как некий наброс на вентилятор (клевета). Впрочем, я на 95% уверен, что это оно и есть, но оставшиеся 5% стоят того, чтобы вот это написать.

Далее, то, что ты пишешь про оптимизации - в корне неверно. Либо какая-то система ставит целью быть high performance - тогда она должна ревностно относиться к любым случаям, когда другая система быстрее, добиваться своего преимущества и доказывать его. SBCL декларируется как high performance, и исключительно поэтому я обратил на него своё внимание. Если бы мне не нужно было performance, я бы уже давно его забыл как страшный сон.

В этом случае «я переписал с С++ на .net и наверняка на лиспе было бы не медленнее» совершенно никуда не годится как обоснование.

Если же система позиционируется как «пригодная для ваших целей», то тогда да, защитник этой системы имеет право спрашивать ботлнеки. Т.е. непонятно, почему я тебе должен что-то предъявлять - мне нужно high performance и SBCL декларируется как high performance. Знаешь ты это или нет, и как ты это не назови, но его performance базируется на выводе типов, на отсечении в рантайме истинных и ложных ветвей, на подстановке специализированных тел функций в зависимости от известных в статике типов аргументов, на вычислениях во время компиляции, на исключении динамических проверок типов, если соответствие типов доказано статически (и для этого вовсе не нужно safety 0). В этом контексте достаточно сказать «неустранимая проверка типов в рантайме», «невозмодно сделать inline из-за отсутствия информации о типах» и все всё сразу поймут. Ты не понимаешь - это вопрос к твоей квалификации, не к моей. Кроме того, предъявлять тебе всё равно нет смысла, поскольку даже свой CLR ты последний раз выкладывал 2 года назад, и практическая польза от тебя строго равна нулю. Если я предъявлю, ты всё равно это не сможешь исправить. Я, например, точно знаю, что я могу в сжатые сроки (за несколько дней) сделать более быстрые типизированные хеш-таблицы для SBCL. Но не буду. Для CCL может быть и сделаю когда-нибудь.

Ладно, давай мы предположим на секунду, что у тебя длиннее. Хотя я, например, исправил https://bugs.launchpad.net/sbcl/ bug/1733622, которая идёт со времён CMU. Stassats сказал, что я там что-то «изуродовал» и патч мой не был принят, но я к этому всерьёз не отношусь, т.к. давно наблюдаю процесс поддержки SBCL. Во всяком случае, SBCL собирается, штатная тест-сюита проходят и бага не проявляется. Помимо этого, я сумел кое-как добавить иммутабельные хеш-таблицы в SBCL. Это тоже никому не нужно (в лиспе же всего хватает, да). Но мой форк умел ругатся во время компиляции при попытке осуществить запись в иммутабельную структуру. Что он не умел - так это корректно обрабатывать момент вызова freeze-object, при котором иммутабельная таблица превращается в мутабельную, поскольку в этом месте происходит небывалое - тип объекта меняется. Система вывода типов SBCL не заточена на такое, именно поэтому возникла та бага. Она наивно полагает, что (cons integer) всегда таковым и останется, и делает оптимизации (которые нельзя отключить, кстати) на базе этой информации. В этом и состоит смысл упомянутой баги. Чтобы решить вопрос с freeze-type, пришлось, бы по сути, перерабатывать вывод типов. Чтобы понять, как он сейчас работает, я решил вооружиться степпером, который в SBCL тоже хронически не работает. Я довольно много поправил в степпере и тут окончательно осознал, что SBCL вообще низкокачественный и что в нём придётся чинить не только вывод типов, а ещё и всё остальное, что команда ничего делать не будет (а на самом деле я могу только реализовать концепт, для доведения до настоящего качества моей квалификации не хватает, нужна помощь команды, а они меня послали) и что мне всё это в сумме на данный момент не потянуть.

Предположим, что ты более меняя преуспел в изучении начинки SBCL (который, кстати, не полностью соблюдает стандарт CL в плане declare и the).

Проблема в том, что слово lattice я не слышал со времён алгебры на мехмате. Поэтому, естественно, я не знаю, что в SBCL не lattice. Я сейчас посмотрел, что такое lattice и из определений я не смог заключить, каким образом в Дельфи Lattice. Но из этого отнюдь не следует, что я не понимаю SBCL - иначе я не смог бы сделать то, что я сделал.

То есть, я считаю, что я достаточно точно понимаю, что есть в системе типов (и в системе контроля типов, если тебе так угодно) CL, SBCL, что из этого мне годится, а чего не хватает.

И вот тут приходишь ты и говоришь, что я не понимаю. Давай, говори, что я конкретно не понимаю. Или это будет просто выглядеть как некий наброс на вентилятор (клевета). Впрочем, я на 95% уверен, что это оно и есть, но оставшиеся 5% стоят того, чтобы вот это написать.

Далее, то, что ты пишешь про оптимизации - в корне неверно. Либо какая-то система ставит целью быть high performance - тогда она должна ревностно относиться к любым случаям, когда другая система быстрее, добиваться своего преимущества и доказывать его. SBCL декларируется как high performance, и исключительно поэтому я обратил на него своё внимание. Если бы мне не нужно было performance, я бы уже давно его забыл как страшный сон.

В этом случае «я переписал с С++ на .net и наверняка на лиспе было бы не медленнее» совершенно никуда не годится как обоснование.

Если же система позиционируется как «пригодная для ваших целей», то тогда да, защитник этой системы имеет право спрашивать ботлнеки. Т.е. непонятно, почему я тебе должен что-то предъявлять - мне нужно high performance и SBCL декларируется как high performance. Знаешь ты это или нет, и как ты это не назови, но его performance базируется на выводе типов, на отсечении в рантайме истинных и ложных ветвей, на подстановке специализированных тел функций в зависимости от известных в статике типов аргументов, на вычислениях во время компиляции, на исключении динамических проверок типов, если соответствие типов доказано статически. В этом контексте достаточно сказать «неустранимая проверка типов в рантайме», «невозмодно сделать inline из-за отсутствия информации о типах» и все всё сразу поймут. Ты не понимаешь - это вопрос к твоей квалификации, не к моей. Кроме того, предъявлять тебе всё равно нет смысла, поскольку даже свой CLR ты последний раз выкладывал 2 года назад, и практическая польза от тебя строго равна нулю. Если я предъявлю, ты всё равно это не сможешь исправить. Я, например, точно знаю, что я могу в сжатые сроки (за несколько дней) сделать более быстрые типизированные хеш-таблицы для SBCL. Но не буду. Для CCL может быть и сделаю когда-нибудь.

Ладно, давай мы предположим на секунду, что у тебя длиннее. Хотя я, например, исправил https://bugs.launchpad.net/sbcl/ bug/1733622, которая идёт со времён CMU. Stassats сказал, что я там что-то «изуродовал» и патч мой не был принят, но я к этому всерьёз не отношусь, т.к. давно наблюдаю процесс поддержки SBCL. Во всяком случае, SBCL собирается, штатная тест-сюита проходят и бага не проявляется. Помимо этого, я сумел кое-как добавить иммутабельные хеш-таблицы в SBCL. Это тоже никому не нужно (в лиспе же всего хватает, да). Но мой форк умел ругатся во время компиляции при попытке осуществить запись в иммутабельную структуру. Что он не умел - так это корректно обрабатывать момент вызова freeze-object, при котором иммутабельная таблица превращается в мутабельную, поскольку в этом месте происходит небывалое - тип объекта меняется. Система вывода типов SBCL не заточена на такое, именно поэтому возникла та бага. Она наивно полагает, что (cons integer) всегда таковым и останется, и делает оптимизации (которые нельзя отключить, кстати) на базе этой информации. В этом и состоит смысл упомянутой баги. Чтобы решить вопрос с freeze-type, пришлось, бы по сути, перерабатывать вывод типов. Чтобы понять, как он сейчас работает, я решил вооружиться степпером, который в SBCL тоже хронически не работает. Я довольно много поправил в степпере и тут окончательно осознал, что SBCL вообще низкокачественный и что в нём придётся чинить не только вывод типов, а ещё и всё остальное, что команда ничего делать не будет (а на самом деле я могу только реализовать концепт, для доведения до настоящего качества моей квалификации не хватает, нужна помощь команды, а они меня послали) и что мне всё это в сумме на данный момент не потянуть.

Предположим, что ты более меняя преуспел в изучении начинки SBCL (который, кстати, не полностью соблюдает стандарт CL в плане declare и the).

Проблема в том, что слово lattice я не слышал со времён алгебры на мехмате. Поэтому, естественно, я не знаю, что в SBCL не lattice. Я сейчас посмотрел, что такое lattice и из определений я не смог заключить, каким образом в Дельфи Lattice. Но из этого отнюдь не следует, что я не понимаю SBCL - иначе я не смог бы сделать то, что я сделал.

То есть, я считаю, что я достаточно точно понимаю, что есть в системе типов (и в системе контроля типов, если тебе так угодно) CL, SBCL, что из этого мне годится, а чего не хватает.

И вот тут приходишь ты и говоришь, что я не понимаю. Давай, говори, что я конкретно не понимаю. Или это будет просто выглядеть как некий наброс на вентилятор (клевета). Впрочем, я на 95% уверен, что это оно и есть, но оставшиеся 5% стоят того, чтобы вот это написать.

Далее, то, что ты пишешь про оптимизации - в корне неверно. Либо какая-то система ставит целью быть high performance - тогда она должна ревностно относиться к любым случаям, когда другая система быстрее, добиваться своего преимущества и доказывать его. SBCL декларируется как high performance, и исключительно поэтому я обратил на него своё внимание. Если бы мне не нужно было performance, я бы уже давно его забыл как страшный сон.

В этом случае «я переписал с С++ на .net и наверняка на лиспе было бы не медленнее» совершенно никуда не годится как обоснование.

Если же система позиционируется как «пригодная для ваших целей», то тогда да, защитник этой системы имеет право спрашивать ботлнеки. Т.е. непонятно, почему я тебе должен что-то предъявлять - мне нужно high performance. В этом контексте достаточно сказать «неустранимая проверка типов в рантайме», «невозмодно сделать inline из-за отсутствия информации о типах» и все всё сразу поймут. Кроме того, предъявлять тебе всё равно нет смысла, поскольку даже свой CLR ты последний раз выкладывал 2 года назад, и практическая польза от тебя строго равна нулю. Если я предъявлю, ты всё равно это не сможешь исправить. Я, например, точно знаю, что я могу в сжатые сроки (за несколько дней) сделать более быстрые типизированные хеш-таблицы для SBCL. Но не буду. Для CCL может быть и сделаю когда-нибудь.