Category: животные

Category was added automatically. Read all entries about "животные".

Book

Играйте на анально огороженных тачках

https://amonitoring.ru/article/steamclient-0day/

TLDR: установленный стим даёт всем желающим эскалацию привилегий

В связи с этим вопрос: как правильно отгородить машины с котиками и прочим инфотейнментом (консоли, мобилы и кофеварки тоже сюда) от машин с работой?

В частности интересно, нужны ли vlan capable switches или условного микротика хватит всем?
Book

"Зависимые" "типы"

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

Слово "типы" зашкварилось тогда, когда Рассел его забыл запатентовать, и его начали использовать для чего попало. Слово "лямбда" зашкварилось, когда Маккарти его украл у Чёрча, забывшего запатентовать. Даже слово "рекурсия" имхо зашкварено рекурсивными программами, т.к. Гёдель его забыл запатентовать. Более свежие зашквары - "нетотальность" зашкварена своим применением для обозначения чего попало. Слово "исчисление" законтачено интегральным исчислением, причём это редкий случай, когда в английском хуже, чем в русском.

Короче, туториалы по непонятным вещам ака НЁХ надо писать такими словами, чтобы не вызывать ложных аллюзий. Где-то видел пародийное объяснение устройства Saturn V словами, понятными ребёнку.

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

Далее, учебник по завтипам надо строить в обратную сторону - от верификации императивщины. Вообще, слово "программа" законтачено, по моему опыту в голове у людей под "программой" подразумевается одно из трёх:

- "семантический паскаль"
- "семантическая джава"
- "семантическая луа"

Надо сразу сказать, что луами занимаются структурные типы (см. тайпскрипт), джавами овнершип типы (см. rust), а мы начнём с того же с чего начали Ada Spark - с даже не семантического паскаля, а семантического ершова: с присваиванием, но без кучи, рекурсии и внешнего мира. Но дополненного эйфелеобразными контрактами - обычными ассертами и ассертами на пре- и постусловия.

Наша игра в подстановки - это не футбол, не дота и не шахматы, а скорее пасьянс, причём ближе к пауку с 4 мастями, которого почему-то все боятся. Программа на семантическом ершове играет роль колоды. Далее компьютер раскладывает эту колоду на игровом поле, а задача человека её сложить. Компьютер, как и в обычном пауке, следит за правилами и дает нам "читы" вроде возможности откатить и переиграть с любого места. Причём если получилось - то у нас не салют, а гарантия того, что в исходном ершове ни один ассерт не сработает. Это не так много, но считается, что этого достаточно, чтобы самолёты не убирали шасси стоя на земле и спутники не отворачивали антенны.

Педагогическая польза этой белиберды в том, что мы заявляем, что паук - это не язык программирования и не язык спецификаций, а некая логика/inference system. Что позволяет абстрагироваться от понятия компайл-рантайма, типов-значений, переменных, времени и т.п. и сосредоточиться на soundness. Т.е. сразу отметаются идеи "добавить в паук присваивание", т.к. любая модификация должна сохранять нашу гарантию.

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

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

И понятно, что формальная система паука не должна в общем случае походить на язык программирования - скажем, discharge of proof obligations by an smt solver or a non-constructive prover достаточно сильно не похоже на чисто функциональную трансляцию исходного ершова.

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

То есть к примеру, мы говорим студенту, что сигма-тип - это не тапл, тип второго элемента которого зависит от рантайм-значения содержащегося в первом элементе, а просто такая хитрая синтаксическая подстановка. Т.е. вот у нас есть (x: A) * B x и это просто 2 куска текста, в котором есть "локальный" кусок, обозначенный "буквой" x, который фигурирует (т.е. "подставлен") сразу во многих местах (подстановка B может быть "сколь угодно нелинейной"). И что эта конструкция нужна, чтобы "давать хинты" движку "пасьянса", какие синтаксические куски у нас "текстуально равны", чтобы ему было легче следить за правилами.

С пями та же самая история но в профиль, а лямбды \(x: A) -> ... - это просто способ изготавливать вторые компоненты-подстановки в сигмах (x: A) * B x и пях (x: A) -> B x

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

C индуктивными типами при таком педагогическом подходе тоже становится понятнее. Нам вообще плевать что у нас есть натуральные которые демонстрируют вычислительную мощь натуральных. Нам важно, что мы можем использовать мощь индукции при манипуляциях в пасьянсе. То есть, нам плевать на обычные элиминаторы, но критически важно (soundness all the way down!), чтобы были индуктивные элиминаторы, традиционно зашкваренно называемые "зависимыми". То есть, чтобы у нас была _доказательная_ мощь _аксиоматической теории_ натуральных, а на вычисление тотальных функций между натуральными нам по большому счёту плевать (и "в самолётах"/ершове натуральных всё равно нету, ибо анальное рабство хард реалтайма и всё преаллоцировано)
Book

Индукция и собачья будка

Разрешимость и даже complexity являются математическими игрушками и часто играют злые шутки с инженерами. Короче, О-нотацию и неразрешимость надо запретить в инженерии, как и индукцию!!!1111 Держать в команде учоного на крайняк, пусть он иногда намалюет сверкающую заоверинжиниренную схему общего вида! А практикам - запретить! Никаких "с иксами задач" и синхрофазотронов буржуазных, только православное конечное и конкретное мышление и троллейбус!

Про будку это мне пример в голову пришёл. Представьте что надо написать программу, создающую будку на Х собак, где Х - натуральное. Но задача не решаема в общем виде! На 1-2 собаки надо делать классическую будку типа Плуто, на 3-10 - вольеры из сетки в ряд, а на большее число - уже целые комплексы в инете я видел, т.к. надо решать совершенно другие проблемы вроде массового выгула.

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

Но то же самое же и с более приземленными программами - например, сортировки. Они всегда нацелены на узкий диапазон параметров и бессмысленны за пределами. Пределы меняются с законом Мура, но всё равно же при смене оборудования переписывать, поскольку меняются узкие места!

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

Короче, основная масса работы - это неуниверсальный код, для которого доказывать что он валиден на всей бесконечности натуральных - это какой-то адов оверинжиниринг. Практики не поймут!
Book

build/foldr fusion, catamorphisms and algebras

Продолжаю описание зоопарка списков в Хаскеле. Бессистемно - сначала хотя бы описать все, а таксономию потом наведём.
-- toChurch l k z = foldr k z l
-- fromChurch g = g (:) []
Катаморфизмы кодировки Чёрча можно записать в "модной" форме через алгебры. Она более удобна, потому что вместо переменного количества аргументов (по одному на конструктор) у нас всегда один аргумент-алгебра:
toAlgebraicChurch l algebra = cata algebra l
fromAlgebraicChurch g = g embed
toAlgebraicChurch . fromAlgebraicChurch = id
Любопытно, что а) сразу получилось обобщение фьюжена на произвольные типы; б) стал понятен физический смысл embed - это выделенная алгебра, декодирующая нашу кодировку Чёрча.

Из любопытства заинлайнил from/to, чтобы получить правило фьюжена в форме cata/build', близкой к foldr/build:
toAlgebraicChurch . fromAlgebraicChurch = id
toAlgebraicChurch (fromAlgebraicChurch g) = g
toAlgebraicChurch (g embed) = g
(\algebra -> cata algebra (g embed)) = g
cata algebra (g embed) = g algebra
cata algebra (build' g) = g algebra
Book

(no subject)

Вот вы говорите "монады", а я подумал тут, и понял, что надо объяснять даже списки. Когда императивщик, у которого в голове смешались подвиды императивных списков, спорит об эквивалентности кода с функциональщикои, у которого смешались подвиды функциональных, я делаю double facepalm. Дискуссия заходит в тупик и/или делаются ложные выводы. Чтобы что-то объяснить, надо пиать целую простыню, и мне обычно облом.

Есть классическая сишная структура односвязного списка, и она - всего лишь метафора, которая постоянно в дискуссиях протекает.
template <typename T>
struct cons
{
	T data;
	cons<T>* next;
};

template <typename T>
struct list
{
	cons<T> *list;
};
Она протекает уже при обсуждении списков в обычных императивных языках, но там это некритично, потому что для всех участников это "очевидно".

Скажем, могут путать list, pointer_list, boxed_list и vector_list:
template <typename T>
struct boxed_list
{
	cons<void*> *list;
};

template <typename T>
struct pointer_list
{
	cons<T*> *list;
};

template <typename T>
struct vector_list
{
	std::vector<T> list;
}
Ещё есть параметры владения, уникальности, константности. Более того, есть итераторы, со своей классификацией (включая инпут-итераторы и т п), которые тоже можно спутать со списками (но не путают, потому что они абсолютно неюзабельны в качестве замены списков). А ещё есть циклические списки, списки, поддерживающие указатель на хвост (и соответственно, конкатенацию за O(1)), списки на деревьях и т.д. И параметры могут комбинироваться (но не произвольно).

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

В первом приближении, есть

а) настоящие списки, похожие на них свёртки и алгебры
б) косписки и похожие на них развёртки и коалгебры

и всё это может быть сделано либо из данных (алгебраиками), либо из кода (кодировка Чёрча), с явной рекурсией или неявной (fix/Fix)
Book

Крокодил не ловится

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

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

Я передавал данные по графу управления только на один "хоп", и поэтому использовал только один адрес - он же адрес ближайшего хопа, он же адрес получателя. А сейчас надо, как это было сделано в примерах хупла, второй уровень адресов-меток организовать - так что будет Map Label (Map Label Fact) вместо просто Map Label Fact.

Ещё я изображал из себя нетипизированного и передавал разные сущности в одном и том же списке. Логически мне приходит

data WithTopAndBot a = Top | Bot | PElem a
data AFType = Call [WithTopAndBot ExpressionFix] | Value ExpressionFix

а я передавал просто [WithTopAndBot ExpressionFix]. А если мне приходило Value ExpressionFix - то я его представлял просто как одноэлементный список с PElem. Всё равно там по контексту можно было отличить, что приходит. Тьфу. Отрефакторил. Теперь хотя бы в диагностике красота.

По мере усложнения внутренней структуры фактов усложняются функции джойна решёток из фактов. Надо придумать, как композиционно эти решётки лепить. У них там ещё не обычные решётки, а инженерные. Джоин некоммутативен, принимает три аргумента и возвращает тапл. А сами решётки сделаны через явные словари. Т.е. вместо
class Lattice a where
   join :: a -> a -> a
   bot :: a
(заметьте, это ж monoid in disguise) у них совершеннейший пиздец в виде
data DataflowLattice a = DataflowLattice  
 { fact_name       :: String          -- Documentation
 , fact_bot        :: a               -- Lattice bottom element
 , fact_join       :: JoinFun a       -- Lattice join plus change flag
                                      -- (changes iff result > old fact)
 }
-- ^ A transfer function might want to use the logging flag
-- to control debugging, as in for example, it updates just one element
-- in a big finite map.  We don't want Hoopl to show the whole fact,
-- and only the transfer function knows exactly what changed.

type JoinFun a = Label -> OldFact a -> NewFact a -> (ChangeFlag, a)
  -- the label argument is for debugging purposes only
newtype OldFact a = OldFact a
newtype NewFact a = NewFact a

data ChangeFlag = NoChange | SomeChange
Завтра буду вводить двухуровневые решётки, будь они неладны, и выделять удаление лишних формальных параметров в отдельный проход.
Book

Сделал решётку

Сделал решётку, а она, собака, не засияла сразу - для print выводится "" вместо Top, т.е. второго вызова "не видно". Проверил в репле, что джоины работают, как нужно, но похоже, что в коде они не вызываются. Либо для Fix инстанс Eq как-то неожиданно определён, так что неравные термы объявляются равными.
Book

(no subject)

Виктор обмазал говном часы.
Александр выебал кошку.
Петр Семенович снял трусы
и выставил жопу в окошко.
Олег сделал штопором дырку в губе.
Вадим наглотался шурупов.
Максим на экране Айфона себе
ключом нацарапал «залупа».
Иван обоссал трамвай на ходу.
Евгений не мылся неделю.
Борис кричал «конгрессменов в пизду»
и начал курить в постели.
Дмитрий чесал отверткой яйцо
и расцарапал до крови.
Павел засунул в духовку лицо
и сжег ресницы и брови.
Руслан выбил палкой четыре окна.
Алексей разломал калитку.
Виктор по-новой набрал говна
и в прихожей слепил пирамидку.
Михаил органично блевал в кусты.
Иннокентий устроил истерику.
Book

Я взяла кухонный нож и кота.

Originally posted by tanyche at Я взяла кухонный нож и кота.
Я взяла кухонный нож и кота.
Я пощупала грудь кота, там билось сердце.
Я отрезала голову коту.
Я отрезала лапу коту.
Я отрезала вторую лапу коту.
Я отрезала третью лапу коту.
Четвертую лапу отрезать коту не смогла.
Я взяла все части кота.
Отнесла их в свинячье корыто.
Бабушкина свинья съела части кота очень быстро.
А я не плакала, я была спокойна.
Ибо сделаю я себе еще одного такого кота.
У меня сохранился биологический материал.
Я сделаю себе еще одного такого кота.