Чтобы самому не забыть, ссылочка на AT команды для модема Huawei E1550.
https://wiki.archlinux.org/index.php/Huawei_E1550_3G_modem#AT_commands
Что-то в оригинальном софте от Укртелекома не нашел какого-нибудь низкоуровенного управления, а через терминалку можно быстренько подтюнить то, что нужно.
Перевести девайс в режим:
AT^U2DIAG=0 -- только модем
AT^U2DIAG=1 -- модем + CD-ROM
AT^U2DIAG=255 -- модем + CD-ROM + Card Reader
AT^U2DIAG=256 -- модем + Card Reader (юзать как обычную флешку)
Easy's blog in Russian
вторник, 4 сентября 2012 г.
пятница, 24 августа 2012 г.
Linkdump: GC and reference types in JVM
GC in Java
- Java SE 6 HotSpot(tm) Virtual Machine Garbage Collection Tuning
- Java Tuning in a Nutshell - Part 1
- Java's -Xmx Heap Settings
- Nice posts series at javaspecialist.ru
- 2 solution of java.lang.OutOfMemoryError in Java
- Java Tuning White Paper
- Stackoverflow: PermGen problems with Lift and Jetty
- Stackoverflow: CMSPermGenSweepingEnabled vs CMSClassUnloadingEnabled
- Stackoverflow: Experiencing >1 second pauses using UseConcMarkSweepGC - help!
Reference types in Java
Просмотрщики pdf
Разгребал собственные заметки, нашел одну старую, о вьюверах. Решил не выбрасывать, а быстренько выложить. Перевел из org-формата в markdown: решил попробовать markdown-mode для подготовки постов. Если бы makrdown-mode умел хотя бы часть того, что в org-mode можно творить со списками, цены бы ему не было.
Для чтения pdf-документов пользуюсь evince. Как-то Иван Мащенко поделился в g+ ссылкой на список pdf-ридеров. Решил потрогать те, что есть в freebsd-портах. Приглянулось только три, но в результате никто не понравился настолько, чтобы заменить им текущий.
Вообщем альтернативы для evince пока нет, особенно после того, как он стал хорошо поддерживать просмотр djvu-формата.
Для чтения pdf-документов пользуюсь evince. Как-то Иван Мащенко поделился в g+ ссылкой на список pdf-ридеров. Решил потрогать те, что есть в freebsd-портах. Приглянулось только три, но в результате никто не понравился настолько, чтобы заменить им текущий.
- ePDFview
- похож на evince,
- нет continuous mode.
- нет перехода назад (после того, как перешел по ссылке)
- шустрый
- поиск текста (и выделение) выделяется странным серым цветом, буквы не видно.
- muPDF
- нет continuous mode,
- шустрый.
- отображение страниц в таск-баре на иконке приложения.
- нет вызова индекса (оглавления).
- легко переходить на страницу по номеру.
- zathura
- средства для букмарков и работы с ними (мне не критично)
- через-чур большая комбинация кейбиндингов и режимов
- переход по ссылкам не курсором мыши, а через хинты (номера), при переходе в режим "идти по ссылкам".
мышь для выделения не работает, хотя в доке это утверждается.
работает только в содержании документа (по клавише Tab) - после перехода по ссылке нет возможности вернуться назад.
в документации не сказано, как это делается (нет кейбиндинга) - нет continuous mode.
- выделение текста через жопу (не понятно, выделил текст, или нет)
- у меня (freebsd + awesome) подвисает (перестает реагировать на клавиши).
это не как тормоза, а будто-бы что-то ломается. - скроллинг мышом работает
Вообщем альтернативы для evince пока нет, особенно после того, как он стал хорошо поддерживать просмотр djvu-формата.
воскресенье, 4 марта 2012 г.
Сердцем чую, 32-битная jvm подводит
Решил выделить чуть больше памяти под jvm, чтобы sbt пошустрее работала. Максимальный размер data segment установлен в 700Mb. Соответственно, указание java выделять под heap больше памяти (параметр -Xmx) кладет ее в корку. Не вопрос, увеличим размер, разрешим выделять памяти побольше. Однако, увеличив параметр ядра kern.maxdsiz до 1200Mb, с удивлением обнаружил что jvm вообще отказывается стартовать, будто ей теперь все время не хватает памяти, при любом запрашиваемом размере хипа. Причем свободной памяти достаточно.
Уже который раз себе говорю, что как разгребусь с рутиной, обязательно назад переползу под 64-битную версию, чтобы впринципе устранить проблемы с адресацией, но все руки не доходят. Жаль только, что в старый ноут больше 4 гиг не влезет. В магазинах ноутовых планок ddr2 по 4 гига не нашел, а было бы неплохо.
UPDATE:
Оказалось, что большой размер data size приводит к тому, что java не может выделить mmap нужного размера, и валится в процессе инициализации vm (нашел перед тем, как самому расчехлить kdump). Так что размер своего data size прийдется закатать обратно.
Уже который раз себе говорю, что как разгребусь с рутиной, обязательно назад переползу под 64-битную версию, чтобы впринципе устранить проблемы с адресацией, но все руки не доходят. Жаль только, что в старый ноут больше 4 гиг не влезет. В магазинах ноутовых планок ddr2 по 4 гига не нашел, а было бы неплохо.
UPDATE:
Оказалось, что большой размер data size приводит к тому, что java не может выделить mmap нужного размера, и валится в процессе инициализации vm (нашел перед тем, как самому расчехлить kdump). Так что размер своего data size прийдется закатать обратно.
суббота, 10 декабря 2011 г.
Старье в портянках
Поглядел на презентации alexott, среди которых есть слайды с выступления на scala.by.
Загрузил проектик, попробовал экспорт из org-mode у себя. Все бы хорошо, но в содержании русские символы не видны, хоть убейся.
Пробовал помудрить с генерируемым tex: менял usepackage местами, добавлял в разных вариациях unicode в hyperref, менял параметры fontenc.
Максимум, чего удалось добится от текса, это сообщения в логе:
Кое-где советуют использовать в заголовках texorpdfstring.
Но, например у Алекса, этого нет, а ведь работает.
Поглядел на teTex-texmf-3.0_8 (из портов), глянул внутрь на пакет hyperref, и ужаснулся: последнее обновление 2006 года.
Вот теперь раздумываю, или самому попробовать установить tex-live, или более интенсивно себе линуксовый дистрибутив присматривать. Хотя возможность обновится появится только в следующем году.
Если честно, то копаться с tex уже нет никакого желания.
Загрузил проектик, попробовал экспорт из org-mode у себя. Все бы хорошо, но в содержании русские символы не видны, хоть убейся.
Пробовал помудрить с генерируемым tex: менял usepackage местами, добавлял в разных вариациях unicode в hyperref, менял параметры fontenc.
\usepackage[T1]{fontenc}
\usepackage[T2A]{fontenc}
\usepackage[utf8x]{inputenc}
\usepackage[russian,english]{babel}
\usepackage[unicode]{hyperref}
\usepackage{ucs}
Максимум, чего удалось добится от текса, это сообщения в логе:
Package hyperref Warning: Glyph not defined in PD1 encoding,
(hyperref) removing `\cyrt' on input line 153.
Кое-где советуют использовать в заголовках texorpdfstring.
Но, например у Алекса, этого нет, а ведь работает.
Поглядел на teTex-texmf-3.0_8 (из портов), глянул внутрь на пакет hyperref, и ужаснулся: последнее обновление 2006 года.
Вот теперь раздумываю, или самому попробовать установить tex-live, или более интенсивно себе линуксовый дистрибутив присматривать. Хотя возможность обновится появится только в следующем году.
Если честно, то копаться с tex уже нет никакого желания.
пятница, 28 октября 2011 г.
Организационная пичалька
Org-mode очень хороший аутлайнер. Не являясь ярым сторонником емакса, я люблю этот mode всем сердцем.
У меня тут и журнал для личного пользования, и домашние дела, и рабочие дела. Рабочие дела, на одной работе, были и в виде каких-то крупных кусков, разбитых на мелкие подзадачи, и в виде справочной информации, и как неоформленные мысли и черновые наброски. Описание проб, итд. Так как рабочий процесс там полностью устаканен, это почти не создавало проблем. Для второй работы тоже пытался его использовать, но не так успешно.
А в чем же проблема? Да дело в том, что на каждой работе есть свои вики, трекеры, итд. Необходимость использовать разных средства организации дел ведет к дублированию, устареванию одной из копий (или в org-mode, или на рабочих ресурсах).
Если какая-то область новая, и какую-то задачу через время уже видишь под совсем новым углом, то на подгонку своих мыслей, примечаний, добавление новой информации, только в одном "органайзере", уходит определенное кол-во усилий, на которое я c радостью готов пойти. Но, кроме этого, больше усилий уходит на синхронизацию разных источников, ведь синхронизация происходит руками. А вот тут и начинается главная проблема. Отказываться от org-mode не хочется, потому что он очень удобный, быстрый, очень гибкий, и не зависит от наличия интернета. Но и дублировать информацию, перенося из одного формата в другой, разбивая по разным сущностям (страницы wiki, milestone, tickets) -- довольно таки трудно и неприятно.
Попал в ситуация, когда на рабочую систему забиваешь, а в org-mode сильно много не плодишь, а пишешь или справочную информацию, или как-то аморфно, просто забивая на конкретизацию. Ведь знаешь, что когда-то все прийдется переносить руками в другую систему, с другой структурой и организацией поддокументов, и будет большое количества мартышкиного труда.
И вот пришло, нужно использовать рабочую систему, и это не какая-то там бюрократия, а элементарная необходимость.
А что делать? Да пока выбор не большой. Коллегам нужно не только видеть план работ и ход его выполнения, перестройки, уточнения, но еще в нем участвовать.
1. Можно было бы воспользоаться имеющимся html-экспортом, на каком-нибудь рабочем ресурсе, и это было бы неплохим выходом, на начальных этапах. Но для перечисленных выше потребностей коллег оно совсем не расчитанно. Так что, увы, отпадает.
2. Полностью валить на рабочую систему, что и будет сделано, в итоге.
3. Использовать org-mode как буфер для небольших кусков, возможно приделав некоторое подобие простого экспорта. Но это костыль и полумера. После экспорта вся гибкость средств оrg-mode полностью теряется. Кто пользовался, тот знает о чем я. Но без средств автоматического переноса это может привести к очередному накоплению и завалу. Но как добавить дела в кучу, чтобы потом рассортировать, вполне может подойти.
Вот такой небольшой фейл использования для работы замечательного средства организации дел. А жаль.
UPD: Если у кого есть мысли или опыт сопряжения org-mode с популярными средствами управления проектами, буду рад услышать.
У меня тут и журнал для личного пользования, и домашние дела, и рабочие дела. Рабочие дела, на одной работе, были и в виде каких-то крупных кусков, разбитых на мелкие подзадачи, и в виде справочной информации, и как неоформленные мысли и черновые наброски. Описание проб, итд. Так как рабочий процесс там полностью устаканен, это почти не создавало проблем. Для второй работы тоже пытался его использовать, но не так успешно.
А в чем же проблема? Да дело в том, что на каждой работе есть свои вики, трекеры, итд. Необходимость использовать разных средства организации дел ведет к дублированию, устареванию одной из копий (или в org-mode, или на рабочих ресурсах).
Если какая-то область новая, и какую-то задачу через время уже видишь под совсем новым углом, то на подгонку своих мыслей, примечаний, добавление новой информации, только в одном "органайзере", уходит определенное кол-во усилий, на которое я c радостью готов пойти. Но, кроме этого, больше усилий уходит на синхронизацию разных источников, ведь синхронизация происходит руками. А вот тут и начинается главная проблема. Отказываться от org-mode не хочется, потому что он очень удобный, быстрый, очень гибкий, и не зависит от наличия интернета. Но и дублировать информацию, перенося из одного формата в другой, разбивая по разным сущностям (страницы wiki, milestone, tickets) -- довольно таки трудно и неприятно.
Попал в ситуация, когда на рабочую систему забиваешь, а в org-mode сильно много не плодишь, а пишешь или справочную информацию, или как-то аморфно, просто забивая на конкретизацию. Ведь знаешь, что когда-то все прийдется переносить руками в другую систему, с другой структурой и организацией поддокументов, и будет большое количества мартышкиного труда.
И вот пришло, нужно использовать рабочую систему, и это не какая-то там бюрократия, а элементарная необходимость.
А что делать? Да пока выбор не большой. Коллегам нужно не только видеть план работ и ход его выполнения, перестройки, уточнения, но еще в нем участвовать.
1. Можно было бы воспользоаться имеющимся html-экспортом, на каком-нибудь рабочем ресурсе, и это было бы неплохим выходом, на начальных этапах. Но для перечисленных выше потребностей коллег оно совсем не расчитанно. Так что, увы, отпадает.
2. Полностью валить на рабочую систему, что и будет сделано, в итоге.
3. Использовать org-mode как буфер для небольших кусков, возможно приделав некоторое подобие простого экспорта. Но это костыль и полумера. После экспорта вся гибкость средств оrg-mode полностью теряется. Кто пользовался, тот знает о чем я. Но без средств автоматического переноса это может привести к очередному накоплению и завалу. Но как добавить дела в кучу, чтобы потом рассортировать, вполне может подойти.
Вот такой небольшой фейл использования для работы замечательного средства организации дел. А жаль.
UPD: Если у кого есть мысли или опыт сопряжения org-mode с популярными средствами управления проектами, буду рад услышать.
пятница, 16 сентября 2011 г.
How to design classes, книжеца
Случайно набрел в еженедельном дайджесте ДОУ на книжку How to Design Classesю Draft: Feb 20, 2011 (pdf). Все авторы известны по, открытой в свободном доступе, образовательной книжке "How to Design Program" (htdp), да одного из авторов (Shiriram Krishnamurthi) помню по книжке "Programming Languages. Application and Interpretation".
Думаю, что полистать будет интересно и может быть даже полезно. Примере на языках scheme и java, дохрена диаграмм классов.
Думаю, что полистать будет интересно и может быть даже полезно. Примере на языках scheme и java, дохрена диаграмм классов.
Подписаться на:
Сообщения (Atom)