1) Самый простой способ показывать исчезнувшие блоки одним цветом, а появившиеся другим. Если изменилось только содержание блока, то можно внутри обойтись традиционными плюсами и минусами
Вообще diff, как средство понимания изменений, годится только для небольших изменений. Если изменения глобальны, то мы имеем труднопонимаемую кашу.
Если diff вас интересует как инструмент создания патчей, то текстовые версии обычного diff могут применимы к программам и ДРАКОН-программам
2) Ctrl-F, вводим слово. Далее среда выделяет один блок, потом другой и т.п.
3) Комиксами трудно нарисовать законы. Комикс — очень трудоёмкий жанр.
Наверное, писали про понятность обычных блок-схем. ДРАКОН — это не обычные блок-схемы. Вот краткое введение.
4) Опять речь идёт об обычных блок-схемах, которые != ДРАКОН-схемам. Ракеты не разрабатывал, но думаю сложность там очень высокая. В одном БУРАНе было около 80 внутренних управляющих систем.
5) Возможно, если в эти продукты ввести поддержку ДРАКОНа, их эффективность повысится.
Тут нужно чётко разделять критику концепции и реализации. Что вы критикуете?
Предположу что концепцию и исходя из этого буду отвечать.
1) Diff — это текстовый инструмент. Возможно для дракона нужны будут новые типы дифов, графические.
Лично я не вижу проблем и с текстовыми дифами: например, в конечном итоге ДРАКОН-Си преобразуется в программу на Си. А сам ДРАКОН-файл можно делать в XML-формате.
2) Соответственно и проблемы поиска нет. Это реализуется в рамках среды.
3) Дракон != обычные блок-схемы. У человека очень значительная часть коры оптимизирована для обработки графики. Текст в большинстве случаев воспринимается хуже блок-схем. Если бы законы составлялись блок-схемами, то тысячам юристам пришлось бы искать другую работу.
4) Главная фишка не в скорости написания, а в скорости понимания + минимизации ошибок в конечном продукте. Дракон в ракетно-космической отрасли был создан. Фишка Дракона — учёт правил эргономики. Блок-схемы на драконе получаются более понятные, чем обычные. P.S. У меня рисовать получается быстрее.
5) Есть гибридный язык ДРАКОН-Erlang. Поддерживается в Drakon Editor.
множество workflow-движков, где реализовано полностью то же самое
Похожее, да не то. Буду благодарен ссылкам на другие движки кроме WWF.
Польза в том, что упрощается процесс алгоритмизации + радикально снижается количество ошибок.
Там в списке есть статья, как парень микроконтроллеры программировал. К ней несколько видеороликов прилагается по среде ИС Дракон (говорят что Drakon Editor попроще будет).
На ДРАКОНе удобно зависывать любую деятельность поддающуюся или нуждающуюся в алгоритмизации. А некоторые программируют на обычных языках в ДРАКОН-средах. Среды, конечно, ещё сыроваты, но разработчики прислушиваются к мнениям и довольно шустро работают.
5 лет пью дистилированную воду (обратный осмос 12 ppm). Недавно сдавал анализ на минералы — по всем норма. В том числе кальций, магний, калий, натрий и т.д.
Питаюсь без фанатизма, витамины и минеральные добавки не употребляю (кроме рыбьего жира и витамина С иногда). Ем овощи, фрукты, молочные продукты (сыр, творог), каши, картошку, рыбу и немного мяса.
Что подтверждает мою теорию о том, что минералы в воде — это «о малое» как говорят математики, которым можно пренебречь.
Тем более минералы в воде из крана на 100% имеют неправильные пропорции. Поэтому некоторые и ставят после обратного осмоса минерализаторы.
Доказательство того, что угольный фильтр практически не снижает минерализацию: попробуй фильтровать солёную воду. После фильтра она останется солёной. Т.е. причина не в том, что в чистую воду попали кусочки угля. Даже если ты бросишь горсть металлических шариков, то проводимость воды почти не изменится.
Да, после того как ты вставишь новый угольный фильтр, первое время проводимость воды будет повышенной, но только первое время, пока не вымоется микропыль.
После этого угольный фильтр практически не вносит вклада в проводимость воды на выходе после него.
А вот, если в фильтре застряли разные микропримеси, то они, действительно, могут потихоньку растворяться водой и увеличивать минерализацию после грязного фильтра.
Интересно почему этот пост заминусовали? Неужели никто не хочет съездить в Кембридж и ещё подзаработать?
Кажется догоняю: время стажировки совпадает с летними каникулами…
Да и список вузов сильно ограничен…
Дело в том, что угольные фильтры почти не уменьшают жёсткость воды. Они хороши против органических соединений, хлора. Прибор у продавца — conductivity meter — меряет проводимость воды, т.е. её общую минерализацию. Поэтому особого эффекта с точки зрения проводимости новый картридж не дал.
Можно и без всяких проблем. В обычной твёрдой пище минеральных веществ в тысячи раз больше, чем в воде. Так что теми минеральными веществами в воде можно принебречь. Есть целые народы, которые всю жизнь пьют либо талую, либо дождевую воду, которые по сути являются дистиллированной водой.
Я вообще не холиварю. И ваш коммент мне нравится и я с ним согласен. Однако, хочу заметить, что в моём тесте попутно со вставкой производилась ещё и индексация по главному глючу.
Ради интереса провёл ещё тест на случайный селект с использованием главного ключа:
833 селекта в секунду. Естественно на таких объёмах данных, где кеширование не работает.
Всё упирается в iops hdd.
И ради интереса провёл тесты на селект на таком объёме, который может влезть в кеш с использованием read ahead:
Кстати, я повторил тест на таком объёме, который гарантированно не влезет в write-cache, поскольку он у меня имеется.
Взял объём данных, который в 10 раз больше моего кеша. Винты шуршали как бешеные.
Получилось 293 544 инсертов в секунду.
Причём тест проводился в виртуальной машине (Vmware Player), что значит на реальном железе будет ещё быстрее.
Ссылка насчёт GAIA интересная, но из неё неясно используется ли SQL-слой для вставки.
То что MUMPS может быстро вставлять записи — известный факт (у меня на домашнем компе, внутри виртуальной машины, 660 000 инсертов в секунду GT.M делает).
В редких БД используется в основном вставка — только во всяких системах логгирования. Для этой задачи, возможно, MUMPS нет равных.
Поэтому мне было интересно как Cache делает SELECT-запросы с джойнами.
В «белых книгах» содержится информация, которая выставляет Cache в хорошем свете, так как всё это размещено на корпоративном сайте Intersystems. И эти книги (про сравнение скоростей) я читал. Мне было интересно ваше мнение как частного лица.
Так что если вы сами не проводили сравнительных тестирований Cache с SQL-базами, то так бы и сказали.
Поскольку автор англоязычен, то он предполагает, что имена компаний состоят из ASCII символов. Код тильды — 126. 127 код у DEL (это непечатный символ).
Иными словами для любого англоязычного справочника верно, что после выражения начинающегося с «B~» идёт, буква C или буквы C нет вовсе.
Таким образом цикл работает до тех пор пока в качестве первой буквы ему не попадётся любая иная буква, чем C.
Я это спрашиваю не для холивара. Просто интересно. Суть вопроса в том, что таблицы эмулируются с помощью глобалов. Т.е. для глобалов это не самый естественный режим работы. Поэтому и интересно.
Если можете сравнить с ораклом, то ещё лучше.
А интересуют меня операции INSERT, SELECT с INNER JOIN, транзакции.
P.S. Ничего не слышал о том, что в mysql повились битмап-индексы. К слову говоря — это ведь не индексы, так как у них скорость работы пропорциональна n, а не log(n).
Вообще diff, как средство понимания изменений, годится только для небольших изменений. Если изменения глобальны, то мы имеем труднопонимаемую кашу.
Если diff вас интересует как инструмент создания патчей, то текстовые версии обычного diff могут применимы к программам и ДРАКОН-программам
2) Ctrl-F, вводим слово. Далее среда выделяет один блок, потом другой и т.п.
3) Комиксами трудно нарисовать законы. Комикс — очень трудоёмкий жанр.
Наверное, писали про понятность обычных блок-схем. ДРАКОН — это не обычные блок-схемы. Вот краткое введение.
4) Опять речь идёт об обычных блок-схемах, которые != ДРАКОН-схемам. Ракеты не разрабатывал, но думаю сложность там очень высокая. В одном БУРАНе было около 80 внутренних управляющих систем.
5) Возможно, если в эти продукты ввести поддержку ДРАКОНа, их эффективность повысится.
Предположу что концепцию и исходя из этого буду отвечать.
1) Diff — это текстовый инструмент. Возможно для дракона нужны будут новые типы дифов, графические.
Лично я не вижу проблем и с текстовыми дифами: например, в конечном итоге ДРАКОН-Си преобразуется в программу на Си. А сам ДРАКОН-файл можно делать в XML-формате.
2) Соответственно и проблемы поиска нет. Это реализуется в рамках среды.
3) Дракон != обычные блок-схемы. У человека очень значительная часть коры оптимизирована для обработки графики. Текст в большинстве случаев воспринимается хуже блок-схем. Если бы законы составлялись блок-схемами, то тысячам юристам пришлось бы искать другую работу.
4) Главная фишка не в скорости написания, а в скорости понимания + минимизации ошибок в конечном продукте. Дракон в ракетно-космической отрасли был создан. Фишка Дракона — учёт правил эргономики. Блок-схемы на драконе получаются более понятные, чем обычные. P.S. У меня рисовать получается быстрее.
5) Есть гибридный язык ДРАКОН-Erlang. Поддерживается в Drakon Editor.
Похожее, да не то. Буду благодарен ссылкам на другие движки кроме WWF.
Там в списке есть статья, как парень микроконтроллеры программировал. К ней несколько видеороликов прилагается по среде ИС Дракон (говорят что Drakon Editor попроще будет).
На ДРАКОНе удобно зависывать любую деятельность поддающуюся или нуждающуюся в алгоритмизации. А некоторые программируют на обычных языках в ДРАКОН-средах. Среды, конечно, ещё сыроваты, но разработчики прислушиваются к мнениям и довольно шустро работают.
Питаюсь без фанатизма, витамины и минеральные добавки не употребляю (кроме рыбьего жира и витамина С иногда). Ем овощи, фрукты, молочные продукты (сыр, творог), каши, картошку, рыбу и немного мяса.
Что подтверждает мою теорию о том, что минералы в воде — это «о малое» как говорят математики, которым можно пренебречь.
Тем более минералы в воде из крана на 100% имеют неправильные пропорции. Поэтому некоторые и ставят после обратного осмоса минерализаторы.
Да, после того как ты вставишь новый угольный фильтр, первое время проводимость воды будет повышенной, но только первое время, пока не вымоется микропыль.
После этого угольный фильтр практически не вносит вклада в проводимость воды на выходе после него.
А вот, если в фильтре застряли разные микропримеси, то они, действительно, могут потихоньку растворяться водой и увеличивать минерализацию после грязного фильтра.
Кажется догоняю: время стажировки совпадает с летними каникулами…
Да и список вузов сильно ограничен…
Мне не нужно подтверждение моих слов ссылкой из документации к бесплатной версии GT.M ))
Последний знак округлён.
Ради интереса провёл ещё тест на случайный селект с использованием главного ключа:
833 селекта в секунду. Естественно на таких объёмах данных, где кеширование не работает.
Всё упирается в iops hdd.
И ради интереса провёл тесты на селект на таком объёме, который может влезть в кеш с использованием read ahead:
1 066 666 селектов в секунду.
Взял объём данных, который в 10 раз больше моего кеша. Винты шуршали как бешеные.
Получилось 293 544 инсертов в секунду.
Причём тест проводился в виртуальной машине (Vmware Player), что значит на реальном железе будет ещё быстрее.
Как бесплатное решение (FOSS — Free and open-source software) действительно GT.M есть только под Unix-подобныи ОС.
Тут указан емейл, где ты можешь заказать версию под другие платформы, чем Unix-подобные:
tinco.pair.com/bhaskar/gtm/doc/books/ao/UNIX_manual/ch02s01.html
А тут указан емейл по которому ты можешь заказать платную поддержку
www.fisglobal.com/products-technologyplatforms-gtm-faq
Сравнение можно проводить если есть хотя бы 2 элемента. А смысла сравнивать каше с каше немного.
Я хоть и не являюсь профессионалом MUMPS, тем не менее на скорость вставки сравнение GT.M с MySql провёл.
А вот на SELECT с джойнами нет, т.к. это долго для простого любопытства.
А ведь это очень важный вопрос. По инсертам всё понятно — MUMPS рвёт всех, а вот по SELECT с джойнами для меня пока вопрос открытый.
То что MUMPS может быстро вставлять записи — известный факт (у меня на домашнем компе, внутри виртуальной машины, 660 000 инсертов в секунду GT.M делает).
В редких БД используется в основном вставка — только во всяких системах логгирования. Для этой задачи, возможно, MUMPS нет равных.
Поэтому мне было интересно как Cache делает SELECT-запросы с джойнами.
В «белых книгах» содержится информация, которая выставляет Cache в хорошем свете, так как всё это размещено на корпоративном сайте Intersystems. И эти книги (про сравнение скоростей) я читал. Мне было интересно ваше мнение как частного лица.
Так что если вы сами не проводили сравнительных тестирований Cache с SQL-базами, то так бы и сказали.
Иными словами для любого англоязычного справочника верно, что после выражения начинающегося с «B~» идёт, буква C или буквы C нет вовсе.
Таким образом цикл работает до тех пор пока в качестве первой буквы ему не попадётся любая иная буква, чем C.
Если можете сравнить с ораклом, то ещё лучше.
А интересуют меня операции INSERT, SELECT с INNER JOIN, транзакции.
P.S. Ничего не слышал о том, что в mysql повились битмап-индексы. К слову говоря — это ведь не индексы, так как у них скорость работы пропорциональна n, а не log(n).