Странно. Кренделей не замечал еще.
Был у меня глюк с винтом однажды. Толи с механикой что, толи электроника барахлила. Суть в том что при попытках чтения данных из начала диска — он израдка выключался. Потом очень долго раскручивался. Поначалу я этого не замечал. Думал что изредкие подвисоны это нормально (а т.к. мак работает очень тихо то огрехи железа я не слышал).
Как сменил винт — зависоны исчезли напрочь.
Мак не выключается теперь месяцами :)
Естественно зависит :)
Посмотрите видео с железячным ускорением при декодировании и без ускорения. Расходы ресурсов будут ощутимо различаться.
Тоже самое и с операционными системами. Например в маке гораздо лучше сделан кеш (за счет этого будет меньше обращений к диску, в случае с SSD это вообще очень хорошо, ибо они могут быстро включатся/выключатся).
Да и хлама в виде кода под 286 процы под макосью не часто встретиш :)
Что такое JIT-компилятор я знаю :)
Писал коммент до того как вы сделали пост про ошибку с веткой.
В контексте iOS JIT звучит очень странно.
Поэтому и решил уточнить, вдруг чего интересного появилось с такой аббревиатурой :)
В статье приведены изменения в сравнении с ios 4.1
Для ипада нужно смотреть изменения: 3.2->4.0, 4.0->4.1, 4.1-4.2 (то что в статье и что еще будет дорабатыватся).
Не совсем так :)
По умолчанию все приложения что уходят в бекгаунд — перестают работать (загруженные ресурсы не освобождаются).
Если же разработчику надо — он может указать что некоторые функции должны продолжать работать на фоне. Этих функций пока 3: воспроизведение аудио, работа с gps, voip (в этом режиме не рвутся сетевые соединения).
Придумайте какойнибудь альтернативный способ преобразования тепловой энергии в электрическую :)
Причем чтобы кпд был хотябы приблизительно как у турбин.
И чтобы более менее надежная система получилась…
Другие способы есть (например термопары) но они не настолько эффективны как старый добрый способ :)
Крайности — это всегда крайности :)
ИМХО для стандартных случаев — лучше использовать стандартне подходы.
Для какихто чуть более сложных случаев — свои компоненты (IB тут действительно почти ничем не поможет, хотя опять же расстановку элементов можно сделать там и не перегружать этой инфой код).
В тяжелых ситуациях (например куча кнопок, анимаций и картинок на фоне сложных расчетов) — наверно стоит подумать про OpenGL (тут уж IB почти не при делах).
И это зря. Саппортить проекты построенные не интерфейс билдером — гораздо сложнее.
Особенно если понадобилось поменять, допустим, цвет шрифта или еще какую мелочь, а создатель проекта не удосужился сделать дефайну (или еще чего подобного) для этого.
В этом случае интерфес билдер ускорит подобный фикс в разы :)
Да и в коде меньше хлама в итоге. Остаются только вещи которые действительно связаны с програмированием (локализиция например).
Кроме того работать с дизайнером гораздо проще получается в IB чем постоянно перекомпиливая проект…
З.Ы. Скорость загрузки данных из xib конешне ниже чем кодом, но в большинстве случаев это абсолютно не критично.
Все хотел вам написать про баг с трофеями жирными. Да все руки не доходили :)
Не знаю есть ли сий баг в новой версии клиента (не часто сечас играю).
Вобщем смысл бага в том что после:
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
Шрифт надписи делался жирным. Но для обычного трофея не сбрасывался в не жирный.
В итоге при определенной последовательности жирных/не жирных трофеях получалась бяка (жирный трофей ушел за экран при скролле, после этого взялся из очереди для выползающей снизу ячейки, но фонт там оставался жирный).
Уже 2 года пишу под ифоны. Проблем с дебагом не возникало…
Разве что в случаях когда я юзаю помесь c++ и Objective-c — то чтобы gdb понял с каким языком я работаю — приходится писать в консоли чтонибудь типа: set language c++
А вообще среда разработки XCode tools — это лучшее что я видел (тем более что еще и без дополнительных затрат, кроме покупки мака).
Обжектив-с — не для игр. Говорю как разработчик игр под iphone. Стоимость посылки одной мессаги в обжективе на несколько порядковы выше чем вызов обычной сишной функции.
Такчто либо тратим кучу процессоронго времени на обработку мессаг, или пишем на старом добром с/с++ (обжектив только для обработки событий от юзера, да на всякие менюшки итп).
Я и скрипты тоже часто юзаю :)
Весь вопрос в скорости создания скрипта (на баше, питоне итп).
В автоматоре быстрее получается. Да и очень удобно сделать себе на рабочем столе папку. Кинул в нее картинку — а там уже пвр :)
Автоматор — это просто вещь. Особенно для программера :)
Часто юзаю когда:
1) дизайнер пришлет 100 картинок с элементами дизайна под ифона разрешением 1351х4587. И нужно перегнать в 320х480…
2) Поменять названия 100 файлов :)
3) из 100 картинок сгенерировать консольной коммандой 100 pvr текстур для opengl.
можно написать вот так (хотя естественно исходный вариант опасный):
id obj = [MyClass alloc];
obj = [obj init];
Был у меня глюк с винтом однажды. Толи с механикой что, толи электроника барахлила. Суть в том что при попытках чтения данных из начала диска — он израдка выключался. Потом очень долго раскручивался. Поначалу я этого не замечал. Думал что изредкие подвисоны это нормально (а т.к. мак работает очень тихо то огрехи железа я не слышал).
Как сменил винт — зависоны исчезли напрочь.
Мак не выключается теперь месяцами :)
Посмотрите видео с железячным ускорением при декодировании и без ускорения. Расходы ресурсов будут ощутимо различаться.
Тоже самое и с операционными системами. Например в маке гораздо лучше сделан кеш (за счет этого будет меньше обращений к диску, в случае с SSD это вообще очень хорошо, ибо они могут быстро включатся/выключатся).
Да и хлама в виде кода под 286 процы под макосью не часто встретиш :)
Писал коммент до того как вы сделали пост про ошибку с веткой.
В контексте iOS JIT звучит очень странно.
Поэтому и решил уточнить, вдруг чего интересного появилось с такой аббревиатурой :)
Для ипада нужно смотреть изменения: 3.2->4.0, 4.0->4.1, 4.1-4.2 (то что в статье и что еще будет дорабатыватся).
По умолчанию все приложения что уходят в бекгаунд — перестают работать (загруженные ресурсы не освобождаются).
Если же разработчику надо — он может указать что некоторые функции должны продолжать работать на фоне. Этих функций пока 3: воспроизведение аудио, работа с gps, voip (в этом режиме не рвутся сетевые соединения).
А так не работает :)
Причем чтобы кпд был хотябы приблизительно как у турбин.
И чтобы более менее надежная система получилась…
Другие способы есть (например термопары) но они не настолько эффективны как старый добрый способ :)
ИМХО для стандартных случаев — лучше использовать стандартне подходы.
Для какихто чуть более сложных случаев — свои компоненты (IB тут действительно почти ничем не поможет, хотя опять же расстановку элементов можно сделать там и не перегружать этой инфой код).
В тяжелых ситуациях (например куча кнопок, анимаций и картинок на фоне сложных расчетов) — наверно стоит подумать про OpenGL (тут уж IB почти не при делах).
Особенно если понадобилось поменять, допустим, цвет шрифта или еще какую мелочь, а создатель проекта не удосужился сделать дефайну (или еще чего подобного) для этого.
В этом случае интерфес билдер ускорит подобный фикс в разы :)
Да и в коде меньше хлама в итоге. Остаются только вещи которые действительно связаны с програмированием (локализиция например).
Кроме того работать с дизайнером гораздо проще получается в IB чем постоянно перекомпиливая проект…
З.Ы. Скорость загрузки данных из xib конешне ниже чем кодом, но в большинстве случаев это абсолютно не критично.
Не знаю есть ли сий баг в новой версии клиента (не часто сечас играю).
Вобщем смысл бага в том что после:
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
Шрифт надписи делался жирным. Но для обычного трофея не сбрасывался в не жирный.
В итоге при определенной последовательности жирных/не жирных трофеях получалась бяка (жирный трофей ушел за экран при скролле, после этого взялся из очереди для выползающей снизу ячейки, но фонт там оставался жирный).
Разве что в случаях когда я юзаю помесь c++ и Objective-c — то чтобы gdb понял с каким языком я работаю — приходится писать в консоли чтонибудь типа: set language c++
А вообще среда разработки XCode tools — это лучшее что я видел (тем более что еще и без дополнительных затрат, кроме покупки мака).
Такчто либо тратим кучу процессоронго времени на обработку мессаг, или пишем на старом добром с/с++ (обжектив только для обработки событий от юзера, да на всякие менюшки итп).
Весь вопрос в скорости создания скрипта (на баше, питоне итп).
В автоматоре быстрее получается. Да и очень удобно сделать себе на рабочем столе папку. Кинул в нее картинку — а там уже пвр :)
Часто юзаю когда:
1) дизайнер пришлет 100 картинок с элементами дизайна под ифона разрешением 1351х4587. И нужно перегнать в 320х480…
2) Поменять названия 100 файлов :)
3) из 100 картинок сгенерировать консольной коммандой 100 pvr текстур для opengl.