Ответ тут: www.viva64.com/ru/b/0132/#ID0EUAAC
Но мне кажется, что авторам стоит сделать Linux-версию лишь для того, чтобы не тратить время, отвечая на этот вопрос в каждом топике (:
> Про «кто хочет — напишет себе плагин» посмеялся. В смысле не будет никто себе плагин писать…
Эээ… Я в некотором замешательстве. Эта вещь точно для программистов?
Достаточно всего одного человека, который сделает плагин и выложит его на github. По крайней мере в мире *nix так принято… И поверьте, такие люди найдутся.
Ну и в качестве небольшого проявления занудстава: XML — это всё же не совсем то, что подразумевается под словами «простой текстовый лог».
Тут скорее требуется следующее:
— текстовый лог должен легко читаться;
— текстовый лог должен иметь структуру, которая легко парситя;
— управление фильтрацией и прочими плюшками делается либо через комментарии, оформленые особым образом, либо через конфигурационный файл (опять-таки, с простой и понятной структурой).
Выполнение данных требований позволит легко осуществить интеграцию с любым IDE с помощью системы плагинов.
Таким образом, мухи получаются отдельно, а котлеты отдельно (статический анализатор сам по себе, а управление осуществляется плагином для конкретной IDE). Кому хочется, пишет плагин для vim, кто-то для emacs на lisp, да хоть для KDevelop или ещё какой экзотики. А если лень плагин писать, а его ещё никто не написал до тебя, то текстовый редактор в зубы и вперёд.
А я предпочитаю LGPL.
С одной стороны код можно линковать с коммерческими проектами, с другой стороны все улучшения в моём коде будут обязаны вернуть в проект. Да, придётся весь код тащить в отдельную разделяемую библиотеку, просто взять и скопировать его к себе лицензия не позволит, но это не большая цена за то, что мой проект будет улучшаться по мере использования другими людьми где бы то ни было.
Проблема пермиссивных лицензий в том, что коммерческие компании не любят возвращать улучшения назад, а данный тип лицензий позволяет им это не делать с чистой совестью.
Другая сторона медали в том, что многие компании, имея выбор между двумя аналогичными по функциональности проектами под LGPL и пермиссивной лицензией, с вероятностью стремящейся к 100% выберут вторую, тут уж ничего не поделать.
Спорно. awk есть практически в любом UNIX-шелле, и как правило, по умолчанию. И он есть даже в BusyBox. Просто затащить perl на embedded железку, у которой всего 4 Mb DataFlash-а вряд ли выйдет.
1) А у некоторых МК нет стека как такового. Например у некоторых МК от Microchip есть стек на 32 адреса, в котором хранятся только адреса возврата из функции и больше ничего там хранится не может.
2) Так там же нет сравнения типа «больше-меньше». Используется сравнение типа ==. То бишь тут проще вычесть одно из другового и смотреть выставился ли флаг Z или нет. Так что эффективность сравнения, как мне кажется, немного притянута за уши.
3) Ну запихивать их в один байт, это уже перебор =) А что касается читабельности, то если переписать числа в hex-е, то станет горяздо нагляднее что делается с nibble'ами %)
Ну разве что в качестве придирки:
1) r3 и r5 никогда не будут больше 3 и 5 соотв., так зачем под них отдавать целых 2+ байт (в зависимости от компилятора). Аналогично с int flag
2) r3, r5, i, flag не могут быть отрицательными по определению, так зачем они signed?
3) читабельность %)
Деление — операция не шибко быстрая, особенно если используемый процессор не имеет блока аппаратного делителя. То бишь получается что сначала поделили на 15, посмотрели остаток, если не угадали, то поделили на 5, снова посмотрели остаток, а если опять не угадали, то делим ещё и на 3. В итоге до трёх делений на итерацию, что, как бы, многовато будет.
Я хоть и не программист, но всё же попробую ради интереса…
Вот функция на Си которая у меня получилась: void foobar(unsigned int n) {
unsigned char is_mul_of_3;
unsigned char is_mul_of_5;
unsigned int i;
for (i = 1; i <= n; i++) {
is_mul_of_3=!(i%3);
is_mul_of_5=!(i%5);
if (!is_mul_of_3 && !is_mul_of_5) {
printf("%d", i);
}
else {
if (is_mul_of_3) printf("Foo");
if (is_mul_of_5) printf("Bar");
}
putchar('\n');
}
}
Теперь собственно говоря почему так, а не иначе:
1) Первым проверяется вариант что число не является кратным ни 3, ни 5. Если посмотрите выборку от 1 до 1000, то получите таких чисел 533, против 467 случаев появления «Foo», «Bar» или «FooBar». Так что проерка на Foo и Bar будут проводиться только в том случае, если хотя бы одно из условий верно.
2) Флаги is_mul_of_3 и is_mul_of_5 вынесены по большей части только для красоты и читаемости, любой современный компилятор всё равно бы оптимизировал повторный вызов !(i % 3). И вообще, целый байт использовать на хранение одного флага не есть гуд, вдруг у нас какой-нибудь микроконтроллер =) Но пусть будет так.
3) Строки «Foo», «Bar» выводятся без символа переноса строки на конце, таким образом строку «FooBar» мы получим автоматически, когда число кратно 3 или 5. puthar в конце сделает нам перенос в любом случае.
4) printf тоже использовать для такой задачи не самая светлая мысль, здесь будет достаточно write. Но так смотрится «читабельнее» и привычне что-ли. Приходилось наблюдать как какой-то компилятор сам менял вызовы printf без параметров на вызов write.
5) Считать начинаем с единицы, а не с нуля, как многие здесь пытались, см. условие задачи.
6) Строки «Foo» и «Bar» должны выводиться _вместо_, а не вместе с числом, опять таки см. условие задачи.
XInput2 — штука хорошая. Правда для полного счастья нужно применять WM с поддержкой множественного фокуса, ибо в KWin это выглядит странно.
Я это использовал вот для чего:
Подключал к компу три клавиатуры и три мыши, спаривал клавиатуры и мыши в пары.
Написал для Wine патч в несколько строк, чтобы тот использовал пару клава+мышь, используя переменную окружения WINE_PTR_ID.
А далее дело техники — запускаем несколько копий Counter-Strike в Wine в оконном режиме, каждой копии передаём свой WINE_PTR_ID, с помощью KWin убираем рамки окон, с помощью wmctrl располагаем окна «мозаикой» на 42" телеке, и можно играть втроём на одной машине.
Ну это в теории, а на практике это было не особо юзабельно, ибо курсор «выпрыгивал» из окна, если резко дёрнуть мышью, и уползал к соседу. С этим я уже бороться не стал.
Не могу понять где здесь проблема…
Для ARM-архитектур никто обратную совместимость не отменял. Вас же не смущает что Debian собранный для armv4 спокойно работает на armv7 процессоре?
Как правило основная головная боль при запуске GNU/Linux дистров на новой ARM-борде — это портирование ядра, а приложения отдельных телодвижений уже не требуют.
В общем, основные пункты:
1. Ubuntu Phone (UP) будет ориентирована на запуск на ядре и драйверах Android, что позволит запустить UP практически на любом существующем Android-смартфоне при наличии root-а.
2. Очень большой упор делается на Web Apps с интеграцией с Ubuntu, а также HUD с активацией онлайн-поиска по различным контент-провайдерам (Amazon, Ebay и пр.).
3. Похоже, что в основе SDK будет лежать Qt+QML, в качестве IDE в ролике показали Qt Creator. Так что будет возможность разработки нативных приложений на C++ (для тех приложений, где скорость критична), а для более простых вещей предлагают использоват QML+JavaScript.
4. Опять таки большой упор Марк делал на идентиточности User Experience для всех типов устройств с Ubuntu (Ubuntu Phone, Ubuntu TV, Ubuntu Desktop).
Надеюсь что не будет как с десктопной версией Ubuntu, где слишком много чего сделано на Python, а иначе есть шанс, что UP будет работать даже медленней, чем Android.
Мне кажется, что название для топика не очень хорошее. Прочитав название, я уж было решил что теперь разработка остановится, пока они не получат свои деньги (фраза «просит деньги» может привести именно к этой мысли). А на самом деле тут всего-лишь объявлен сбор пожертвований, что для Open Source проекта дело вполне обыденное.
Вообще документация к ядру меня в своё время очень порадовала, написано людьми для людей.
Но мне кажется, что авторам стоит сделать Linux-версию лишь для того, чтобы не тратить время, отвечая на этот вопрос в каждом топике (:
Эээ… Я в некотором замешательстве. Эта вещь точно для программистов?
Достаточно всего одного человека, который сделает плагин и выложит его на github. По крайней мере в мире *nix так принято… И поверьте, такие люди найдутся.
Ну и в качестве небольшого проявления занудстава: XML — это всё же не совсем то, что подразумевается под словами «простой текстовый лог».
— текстовый лог должен легко читаться;
— текстовый лог должен иметь структуру, которая легко парситя;
— управление фильтрацией и прочими плюшками делается либо через комментарии, оформленые особым образом, либо через конфигурационный файл (опять-таки, с простой и понятной структурой).
Выполнение данных требований позволит легко осуществить интеграцию с любым IDE с помощью системы плагинов.
Таким образом, мухи получаются отдельно, а котлеты отдельно (статический анализатор сам по себе, а управление осуществляется плагином для конкретной IDE). Кому хочется, пишет плагин для vim, кто-то для emacs на lisp, да хоть для KDevelop или ещё какой экзотики. А если лень плагин писать, а его ещё никто не написал до тебя, то текстовый редактор в зубы и вперёд.
С одной стороны код можно линковать с коммерческими проектами, с другой стороны все улучшения в моём коде будут обязаны вернуть в проект. Да, придётся весь код тащить в отдельную разделяемую библиотеку, просто взять и скопировать его к себе лицензия не позволит, но это не большая цена за то, что мой проект будет улучшаться по мере использования другими людьми где бы то ни было.
Проблема пермиссивных лицензий в том, что коммерческие компании не любят возвращать улучшения назад, а данный тип лицензий позволяет им это не делать с чистой совестью.
Другая сторона медали в том, что многие компании, имея выбор между двумя аналогичными по функциональности проектами под LGPL и пермиссивной лицензией, с вероятностью стремящейся к 100% выберут вторую, тут уж ничего не поделать.
Так это тоже хорошо =)
Только для таких целей, как мне кажется, awk лучше подойдёт:
Ибо не пораждает кучу процессов с последующей проверкой статуса выхода, а соответсвенно работает гораздо быстрее. А так на вкус и цвет, конечно же.
2) Так там же нет сравнения типа «больше-меньше». Используется сравнение типа ==. То бишь тут проще вычесть одно из другового и смотреть выставился ли флаг Z или нет. Так что эффективность сравнения, как мне кажется, немного притянута за уши.
3) Ну запихивать их в один байт, это уже перебор =) А что касается читабельности, то если переписать числа в hex-е, то станет горяздо нагляднее что делается с nibble'ами %)
Ну разве что в качестве придирки:
1) r3 и r5 никогда не будут больше 3 и 5 соотв., так зачем под них отдавать целых 2+ байт (в зависимости от компилятора). Аналогично с int flag
2) r3, r5, i, flag не могут быть отрицательными по определению, так зачем они signed?
3) читабельность %)
Случайно использовал тег code вместо source.
Ещё раз:
Вот функция на Си которая у меня получилась:
void foobar(unsigned int n) { unsigned char is_mul_of_3; unsigned char is_mul_of_5; unsigned int i; for (i = 1; i <= n; i++) { is_mul_of_3=!(i%3); is_mul_of_5=!(i%5); if (!is_mul_of_3 && !is_mul_of_5) { printf("%d", i); } else { if (is_mul_of_3) printf("Foo"); if (is_mul_of_5) printf("Bar"); } putchar('\n'); } }Теперь собственно говоря почему так, а не иначе:
1) Первым проверяется вариант что число не является кратным ни 3, ни 5. Если посмотрите выборку от 1 до 1000, то получите таких чисел 533, против 467 случаев появления «Foo», «Bar» или «FooBar». Так что проерка на Foo и Bar будут проводиться только в том случае, если хотя бы одно из условий верно.
2) Флаги is_mul_of_3 и is_mul_of_5 вынесены по большей части только для красоты и читаемости, любой современный компилятор всё равно бы оптимизировал повторный вызов !(i % 3). И вообще, целый байт использовать на хранение одного флага не есть гуд, вдруг у нас какой-нибудь микроконтроллер =) Но пусть будет так.
3) Строки «Foo», «Bar» выводятся без символа переноса строки на конце, таким образом строку «FooBar» мы получим автоматически, когда число кратно 3 или 5. puthar в конце сделает нам перенос в любом случае.
4) printf тоже использовать для такой задачи не самая светлая мысль, здесь будет достаточно write. Но так смотрится «читабельнее» и привычне что-ли. Приходилось наблюдать как какой-то компилятор сам менял вызовы printf без параметров на вызов write.
5) Считать начинаем с единицы, а не с нуля, как многие здесь пытались, см. условие задачи.
6) Строки «Foo» и «Bar» должны выводиться _вместо_, а не вместе с числом, опять таки см. условие задачи.
Если не секрет, а чем libvirtd + virt-manager не устроили?
Я это использовал вот для чего:
Подключал к компу три клавиатуры и три мыши, спаривал клавиатуры и мыши в пары.
Написал для Wine патч в несколько строк, чтобы тот использовал пару клава+мышь, используя переменную окружения WINE_PTR_ID.
А далее дело техники — запускаем несколько копий Counter-Strike в Wine в оконном режиме, каждой копии передаём свой WINE_PTR_ID, с помощью KWin убираем рамки окон, с помощью wmctrl располагаем окна «мозаикой» на 42" телеке, и можно играть втроём на одной машине.
Ну это в теории, а на практике это было не особо юзабельно, ибо курсор «выпрыгивал» из окна, если резко дёрнуть мышью, и уползал к соседу. С этим я уже бороться не стал.
Для ARM-архитектур никто обратную совместимость не отменял. Вас же не смущает что Debian собранный для armv4 спокойно работает на armv7 процессоре?
Как правило основная головная боль при запуске GNU/Linux дистров на новой ARM-борде — это портирование ядра, а приложения отдельных телодвижений уже не требуют.
1. Ubuntu Phone (UP) будет ориентирована на запуск на ядре и драйверах Android, что позволит запустить UP практически на любом существующем Android-смартфоне при наличии root-а.
2. Очень большой упор делается на Web Apps с интеграцией с Ubuntu, а также HUD с активацией онлайн-поиска по различным контент-провайдерам (Amazon, Ebay и пр.).
3. Похоже, что в основе SDK будет лежать Qt+QML, в качестве IDE в ролике показали Qt Creator. Так что будет возможность разработки нативных приложений на C++ (для тех приложений, где скорость критична), а для более простых вещей предлагают использоват QML+JavaScript.
4. Опять таки большой упор Марк делал на идентиточности User Experience для всех типов устройств с Ubuntu (Ubuntu Phone, Ubuntu TV, Ubuntu Desktop).
Надеюсь что не будет как с десктопной версией Ubuntu, где слишком много чего сделано на Python, а иначе есть шанс, что UP будет работать даже медленней, чем Android.
Определенно лучше =)
Вообще на Kernelnewbies можно найти много полезных вещей.