> При этом MyISAM таблицы повреждаются очень просто — с этим проблем нет никаких.
На мой неискушённый взгляд, это веский повод не использовать MyISAM вообще.
Кстати, процессор, на котором исполняется код. В теории, Objective-C должен обладать той же проблемой, если Apple не принял каких-то дополнительных усилий.
Но в любом случае, инструментарий довольно широк:
@synchronized
GCD
pthread_*_lock.
Будет время — оттестирую.
Ну, с наукой в универах у нас не всё так плохо. Например, у нас в Калининграде в БФУ суперкомпьютер стоит уже лет 5 как. Какие-то рассчёты там на нём проводят регулярно, видимо есть что считать :)
Согласен. Но по сравнению с одиночной головкой оно таки тяжелее. Устройство из топика — это модификация системы подачи прута, головка головка принтеру нужна одна. Главный минус — нужно предсказывать расход прута с идеальной точностью, что может быть проблемой, на мой взгляд.
В этой ветке речь шла не о том, а о трудностях передачи уровня рекурсии в рекурсивную функцию.
И передавать параметр в хвостовую рекурсию не я собирался :P
Я просто обращаю внимание на то, что этот аргумент не состоятелен, так как такой тип рекурсии легче всех прочих раскрыть вручную. Не касаясь других типов рекурсии.
Если вы не знаете, будет ли развёрнута рекурсия — проще развернуть сразу вручную. Благо делается это тривиально: оборачиваем всё в цикл и перезаписываем значения переменных новыми в конце итерации.
А зачем в хвостовую рекурсию протаскивать глубину, если она будет развёрнута? Если же она развёрнута не будет — то и дополнительный индекс ни на что, кроме максимальной глубины, не повлияет.
Хм. Это уже интересней. Хотя 3 радиатора всё равно на месте. Хотя всё это всё равно увеличивает вес головки и требует более прочной рамы.
Насколько я вижу у этого варианта из плюсов:
— намного проще синхронизация
— нет сложной механики
из минусов
— дополнительный вес на подвесе
— количество цветов ограниченно числом каналов в головке
Насколько я вижу — принцип действия разных. По вашей — 1 головка с несколькими нагревателями для разных нитей и 1м соплом, что позволяет не перепозиционировать печатующую головку при смене цвета.
Здесь же — устройство, разрезающее и сплавляющее несколько нитей в одну цветную. При этом в самом принтере нужен только 1 нагревательный элемент и много много синхронизации. Кстати, довольно очевидная идея, первая (и единственная), что пришла в голову для многоцветной печати одной головкой.
В любом случае, всегда можно попробовать эмулировать рекурсию: создать стек в куче и складывать туда старые значения переменных вместо ухода в глубь рекурсии. Это попрежнему будет есть память, но, по крайней мере, это будет память кучи а не стека.
Почему бы не сделать это на карте? Сейчас там происходит нечто непонятное — выделяются какие-то блоки, возможно просто стандартная подсветка браузера. Что оно символизирует — я так и не понял.
Как мне прокрутить страницу мышью. Скролбар я могу схватить мышью и тягать его вверх-вниз плавно переходя между разными частями страницы. Как сделать аналогичное действие вашим контролом?
От этого никто не застрахован. Стандарт может быть не соблюдён вне зависимости от качества кода. Но всё таки лично для меня при выборе библиотеки из множества вариантов качество кода выступает первым фильтром. Фанатизмом не страдаю, но откровенный говнокод не возьму.
К сожалению нет. Я бы попробовал Skyforge, хотя бы просто из любопытства, что же у вас получилось. Но останавливает меня именно то, что разработчик и паблишер — mail.ru.
Вы пишете отличные технические, соглашусь, но практика с ArchAge показывает, что ничего не изменилось. И это печально.
> Хороший код может содержать больше багов, чем плохой
Могу представить только одну ситуацию, в которой это возможно: плохой код оттестирован, а хороший нет.
В любом случае, баги в удачном коде править проще, чем в неудачном. И, вполне вероятно, один единственный плавающий баг неудачного кода может запросто превысить время отлова 10ти багов в удачном.
В результате после просмотра кода ты имеешь представление, что от этой библиотеки ожидать, и если там что-то сильно не так — лучше я добавлю недостающий функционал другую библиотеку, чем возьму эту.
> Чем ты руководствуешься при выборе сторонней библиотеки: тем, какой в ней классный код, или тем, какие крутые вещи она умеет делать? Ты хоть заглядываешь в ее код после установки?
А вот кстати, таки кодом. Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
Потому как если код библиотеки плох — шанс содержания багов в нём выше и вероятность того, что мне придётся писать костыли для либы резко возрастает. Если, на проверку, она вообще сможет выполнять свои обязанности.
На мой неискушённый взгляд, это веский повод не использовать MyISAM вообще.
Но в любом случае, инструментарий довольно широк:
@synchronized
GCD
pthread_*_lock.
Будет время — оттестирую.
Пс. ой, какую археологию я устроил :D
И передавать параметр в хвостовую рекурсию не я собирался :P
Я просто обращаю внимание на то, что этот аргумент не состоятелен, так как такой тип рекурсии легче всех прочих раскрыть вручную. Не касаясь других типов рекурсии.
То есть — это не часть библиотеки? Тогда я записываюсь в список противников :)
Насколько я вижу у этого варианта из плюсов:
— намного проще синхронизация
— нет сложной механики
из минусов
— дополнительный вес на подвесе
— количество цветов ограниченно числом каналов в головке
Здесь же — устройство, разрезающее и сплавляющее несколько нитей в одну цветную. При этом в самом принтере нужен только 1 нагревательный элемент и много много синхронизации. Кстати, довольно очевидная идея, первая (и единственная), что пришла в голову для многоцветной печати одной головкой.
Вы пишете отличные технические, соглашусь, но практика с ArchAge показывает, что ничего не изменилось. И это печально.
Могу представить только одну ситуацию, в которой это возможно: плохой код оттестирован, а хороший нет.
В любом случае, баги в удачном коде править проще, чем в неудачном. И, вполне вероятно, один единственный плавающий баг неудачного кода может запросто превысить время отлова 10ти багов в удачном.
В результате после просмотра кода ты имеешь представление, что от этой библиотеки ожидать, и если там что-то сильно не так — лучше я добавлю недостающий функционал другую библиотеку, чем возьму эту.
А вот кстати, таки кодом. Если есть выбор из двух и более вариантов — я сначала загляну в код библиотек, а уже только потом попробую те, чей код меня удовлетворил.
Потому как если код библиотеки плох — шанс содержания багов в нём выше и вероятность того, что мне придётся писать костыли для либы резко возрастает. Если, на проверку, она вообще сможет выполнять свои обязанности.