Количество программ для Android превысило 40 тысяч

> Кстати, как впечатления от MID?


отличный аппарат, своих денег стоит имхо.

Панятна. В общем, ждём нокию с полноценным линуксом.

С мобильными платформами так дела обстоят:

Жаба была бы на самом деле весьма хороша, если бы приложение на жабе запускалось бы на всех жабных платформах. Так ведь хрен там - MIDP срань какого-то хрена отказывается работать в виде броузерного апплета через жабоплагин, а хрень под JRE не запускается на ведроидах и всё такое. Поэтому такую жабу - в топку. Вся полезная жабная идея байткода (это единственная полезная жабная идея, ради которой можно было бы пожертвовать производительностью и памятью) спущена в канализацию. Ну и накой чорт нужно стопицот разных жаб, никак друг-с-другом не совместимых?

Симбмиан - уже лучше, сидючи в Linux можно как-то там вдоволь намучившись с OpenC, кросс-тулзами и Symbian SDK сделать make и получить ТАКОЙ ЖЕ как на большой машине ping или там traceroute.
Впрочем, без бубна не обойтись, если чего посложнее захочется на телефоне иметь.

Винмобайл ... (/me ушёл блевать)

Остаётся на сегодня только ARMовый порт Linux. Тут хоть какая-то переносимость софта есть. Ещё бы все эти МееГо/Маемо/кто-там-ещё пилили бы стандартный Debian, под свои процессоры и видео со звуком, вместо того, чтобы дрочить вприсядку с идиотскими недодистрибутивами и проприетарными, итить их в ту люсю /bin/blink-once-this-nice-green-led, /bin/turn-on-backlight и /lib/..../kernel/drivers/misc/perdelka_gpio_drv.ko (вот за эту дебильную дрянь вообще надо на кол сажать уродов. Сцуко, как будто, млять, нет в мире большей тайны, чем то, как они там в своей версии reference design очередного SoC навешали на GPIO всякие питания GSM модема и светодиодики с кнопочками ).

Все верно, причем все и так уже знают большинство их «секретов» ))

Только судя по Texas Instruments с их омапами, они сначала релизят чип, а потом только начинают под него писать дрова...

До сих пор ведь многого из их же документации не поддерживается никаким кодом...

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

Мультидиспатчинг несложно пишет на рефлекшне, но во-первых медленно получается, во-вторых плохо сопровождаемо.

но как насчет работы при наличии класслоадера и прочего?

Чем он мешает?

Лять, открой хотя бы ту же википедию и прекрати позориться, специалист ты доморощенный...

>Motorola Milestone, например, доступен для предзаказов. Начало продаж 15-18 апреля.

14-го только на таможне появится, если опять не перенесут. Развозить начнут с 20-го.

Ну а серый можно купить уже сейчас.

>Симбмиан - уже лучше, сидючи в Linux можно как-то там вдоволь намучившись с OpenC, кросс-тулзами и Symbian SDK сделать make и получить ТАКОЙ ЖЕ как на большой машине ping или там traceroute.

В последнее время очень сырые и тормознутые прошивки.

E71 - был последний мой телефон на симбиане. Хорошая штука была. Но когда я взглянул на 5800, а затем на N97, то понял, что больше у меня симбианов не будет.

Ну такое случается не часто. Не чаще чем жава программы падают с трейсом на пару десятков килобайт.

конец скоро придет iphone за бобло такое продавать!

Если случился коредамп по вине пользовательского приложения, то такая > операционка отвратительно спроектирована и не годна к серьёзному использованию.

Ты путаешь kernel panic и core dump. Это разные вещи :)

http://en.wikipedia.org/wiki/Core_dump

кора - это образ сдохшей проги, аналог жавовского heap dump. Точнее java heap dump - аналог core dump. http://java.sun.com/javase/6/docs/technotes/tools/share/jhat.html

Один минус - это ее размер. Но ковырятся в ней (если стек не порушен) проще, чем разбираться в java stack trace, т.к. в jst нету информации о состонянии перменных. в core dump есть все (включая регистры).

>> и написание selinux правил и приложений под это дело превращается в утонченные BDSM игры.

я к тому, что я вот щас могу взять SDK андроида и за 15-20 минут (зная жабу только на уровне «немного писал чиста пазырить что это такое») наклепать простейший хеловорлд.

сколько это времени займет в предложенном случае с Qt и selinux? :)

На Qt под симбиан - легко! selinux - не нужен.

Проблема только в том, что он только что появился. Опоздали чутку. Но, думаю, наверстают.

Не, ну так палиться - перебор. Советую теперь ник сменить. Раскрылся полностью, можно сказать.

Ну такое случается не часто. Не чаще чем жава программы падают с трейсом на пару десятков килобайт.

Это где такие монстры обитают? На LOR'e и то — максимум одна страничка стэктрейса бажной JSP.

>кора - это образ сдохшей проги, аналог жавовского heap dump.

А, ясно! Сишники так отлаживают свои программы для юзерспейса? Сурово.
А почем бы не взять gdb или DTrace чтобы оттрассировать цепочку вызовов и состояние переменных, регистров БЕЗ ухода в кору?

> Мультидиспатчинг несложно пишет на рефлекшне, но во-первых медленно получается, во-вторых плохо сопровождаемо.

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

А, ясно! Сишники так отлаживают свои программы для юзерспейса? Сурово.

Не. Они отлаживают как и мы в java gdb (или что там есть из сейчас из обрерток типа ddd) + printf :).

А вот када прога падает, в c/c++ можно протись по стеку и посмотреть состояние данных в момент падения. А по stack tracе нихрена узнать нельзя.

Пример: есть куча данных в csv формате и мы их в цикле жуем, как-то так

while ((input = linereader.read()) != null) {
  String[] fld = input.split();
  long val = Long.parseLong(fld[3]);
}

Так что core dump очень удобен (не знаю, есть ли такая возможность в винде, но в linux когда я писал на с/c++ это жутко здорово помогало

4.2 man NumberFormatException. Эта информация содержится прямо в message у исключения. Так что стэктрейс эту информацию выдаст.

>А, ясно! Сишники так отлаживают свои программы для юзерспейса? Сурово.

Ну если ты в жабе отлаживаешь программы по стектрейсу после краша - тогда да, сишники отлаживают по коре после падения.

Не кривляйся, уже не поможет.

>ну про (3) слабые ссылки надеюсь ясно, что они имеют отношение к «реализации интерфейса»? вот и ответь, как, реализуются ли они через JNI?

Наследуйся от *Reference и делай native методов сколько хочещ.

>Ну если ты в жабе отлаживаешь программы по стектрейсу после краша

В том то и дело что появление исключения не вызывает краша. А возможности коре-дампа в джаве еще богаче - man jstack, jmap, etc.

Как скажешь.

> Вот MS Office — программа

Это программный комплекс

что оно упало в строке с parseLong, но узнать в какой строке входного файла

4.2 man NumberFormatException. Эта информация содержится прямо в message у исключения. Так что стэктрейс эту информацию выдаст.

Маладец. Я рад что ты знаешь это. Осталось выяснить номер строки во входном файле.

ЗЫ: это была просто иллюстрация, т.к. нигде не было сказано, что Long - это java.lang.Long, а не допустим my.hack.Long :)

http://www.mobile-review.com/fullnews/main/index.shtml?28875#28875 -по теме

>Осталось выяснить номер строки во входном файле.

Ну и где в том коде счетчик номера строки? ;) Или gdb таки слинокван с либастралом?

:) можно просто посмотреть всю строку в отладчике (в корке) или банально посмотреть в LineNumberingReader (если он используется). Или еще по тыщи и одному критерию. Суть в другом - в корке можно увидить все.

В общем мы отклонились от темы. Суть - стектерйс - херня, которая мало что говорит о _состоянии_ программы в момент падения. А упала она вся (в случае с fork это не проблема) или только поток - смысл один и тот-же: какая-то функциональность не работает и понять почему без входных данных нельзя (по этому надо писать кучу логов).

>Суть - стектерйс - херня, которая мало что говорит о _состоянии_

У стэктрейса задача другая. Указать где произошло исключение. Быстро. Лично я в 90% случаев понимаю в чем дела по хорошему стэктрейсу. Генерить полный дамп ооочень медленно и нужно в редких случаях. Именно для них в джаве есть специальные тулзы о которых я уже писал.