Алексей: "Кстати, может быть человеку не хватает ссылок на соответствующие страницы оффдокументации?" человек не спрашивал, как поставить ghc на Windows. Он искал уроки по языку. Вот только монада она что на Win монада, что на Linux. Вся стандартная библиотека и подавляющая часть пакетов из stackage/hackage не привязаны ни к какой ОС.
Алексей: "They should run on older Windows installs as well, but have not been tested. If you do test, please edit and update this page to indicate as such."
Вы путаете тёплое с мягким. Не запуститься может банально из-за несовместимости api/abi. Или из-за отсутствия какого-нибудь sse (не конкретно к ghc, а вообще).
Но никакая unix-консоль не нужна. От слова совсем. Тех инструментов, что есть в XP из коробки достаточно для запуска cabal и stack. Всё, что требуется дополнительно, haskell-platform несёт с собой.
Евгений Иванович всё правильно. Валидации в алгоритме нет. Но она есть в протоколах, которые используют RSA. GPG, например, дописывает к данным контрольную сумму. И тогда при дешифровке можно проверить валидность.
Максим Корольский: 300 баксов это за то, что бы стать арендатором. Т.е. домен уже кто-то арендует, и он готов вам передать это право аренды за 300 баксов.
А сама аренда стоит в районе 5-20 долларов в большинстве зон. В com около сотни может выходить.
Роман Башарин: вы можете хоть сотню коммитов сделать. А затем squash. Проблем нет.
rebase может вести себя как squash, но не наоборот. Rebase более гибкий инструмент только и всего. И ещё раз повторюсь - правил нет. Это лишь моё мнение. Кто-то вам посоветует делать всё наоборот и будет прав.
Роман Башарин: если же в ветке была такая работа, что грамотный ребейз сделает из ветки один коммит, то от свквоша это не будет отличатся (за исключением наличия мерж-коммита, который тоже можно убрать через ff).
Один офигенный коммит должен быть атомарным.
Что это значит?
1) Он должен быть рабочим. В идеале вы должны иметь возможность переключится на совершенно любую версию проекта, и она будет работать.
2) Он должен содержать лишь одно законченное изменение. В одном коммите не должно быть 2 фичи.
Для этого используется не squash (что в идеале вообще не должно использоваться), а rebase.
Т.е. после того, как вы сделали фичу, эту ветку нужно заребейзить - удалить отладочные сообщения, разбить коммиты на логические части. И, возможно перенести базу на последнюю версию.
Для чего это нужно:
1) Посмотрите на исходники linux. Там каждые 2.5 месяца десятки тысяч коммитов вливается. Если в этих коммитах будет промежуточный код (отладочные сообщения, неудачные реализации), то это невозможно будет читать. Мы можете затронуть во время работы сотню строк кода, а в итоге реальных изменений останется десяток. Другие разработчики с ума сойдут, читая ход ваших мыслей. Поэтому большинство коммитов в linux имеют размер в пару строк. Разработчик оставляет минимально необходимый патч. Это легко читать другим разработчикам.
2) Коммиты должны быть рабочими. Когда вам приспичит воспользоваться такими инструментами как bisect, вы будете проклинать себя за то, что ваш коммит не собирается и вы не можете его проверить.
Это может показаться сложно и нудно. Относитесь к этому как к части своих обязанностей. Вам же приходится работать с багтрекером, например, это не относится напрямую к программированию. Так же и система контроля версий не относится к программированию.
Подводя итог: в личной ветке делаете что угодно. Когда работа закончена, делаете ребейз, причёсываете коммиты. А затем делаете мерж без всяких squash и ff.
Большинство открытых проектов вас пошлют куда подальше, если вы пришлёте им не причёсанный патч. Даже если там будет супер-мега фича.
padlyuck:
Вы предложили сделать в точности то, от чего автор пытается избавиться.
И если ветка смержена, то удалив её, вы удалите лишь указатель (на вашем скрине зелёный лейбл feature). Коммиты никуда не денутся и останутся в истории.
std::string;