Всем здравствуйте.

На снимке – эксперименты, являющиеся продолжением вот этой темы.

Как уже не в первый раз убеждаюсь, утилита strace с ключом -k (печатать stack trace каждого вызова) – прекрасный инструмент для первичного (грубого) поиска проблемы. Собственно, именно таким способом было выяснено, что на Debian 9 и Debian 10+ поведение java начинает различаться, начиная с инструкции <open64_w+22> из libhpi.so. В результате последовательность

b main
r
b open64_w
cont

позволяет вплотную подобраться к проблеме, но уже пер-ректально «изнутри».

На снимке – сравнение консольного интерфейса GDB (слева) и Emacs (справа). Если честно, Emacs’ом для отладки пользовался в первый раз в жизни – и он мне понравился. Понравился даже больше, чем старик DDD, который умные люди используют для полноценной визуализации данных в памяти, но вот мне самому как-то не доводилось.

В чём ценность cgdb как обёртки над gdb, особенно в отсутствие исходного кода, – я так и не понял. Если у вас есть успешный успех опыт использования cgdb – поделитесь, пожалуйста. Аналогично, xxgdb, наверное, хорош – но для того, чтобы он завёлся в 2023 году, мне надо выкинуть из ~/.gdbinit буквально всё.

За каким рожном нужен убогий и деревянный как Буратино Nemiver, по недосмотру появившийся в пакетах Debian и заявляющий в качестве ключевых особенностей совместимость с GNOME 3 и умение скопировать значение переменной в буфер обмена (я не шучу: «Ability to copy the content of a variable into the GTK clipboard») – я тоже не понял. Зачем, если есть прекрасный Emacs?

В сухом остатке: насколько я понял, ebp + 0x8, ebp + 0xc и ebp + 0x10 – это адреса параметров функции. По первому адресу лежит строка, и строка эта на Debian 9 и Debian 10 разная:

• /usr/lib/jvm/java-1.3.1_20-sun-i386/jre/lib/rt.jar (нормальное поведение, слева) и
• /usr/lib/jvm/java-1.3.1_20-sun-i386/jre (аномальное, справа).

Стало быть, ерунда начинается ещё до системного вызова open()/openat() и происходит в одном из пяти вызовов:

1. sysOpen(...)
2. JVM_Open(...)
3. ZIP_Open_Generic(...)
4. ZIP_Open(...)
5. ClassLoader::setup_bootstrap_search_path(void)

Будем копать дальше.

>>> Просмотр (3840x2160, 853 Kb)

Всем здравствуйте.

На снимке – промежуточный результат эксперимента, описанного несколькими днями ранее.

В виртуальной машине работает Red Hat Linux 7.1 с KDE2, используя для отрисовки современный X-сервер на настоящем железе. Кстати, чёрное окно VirtualBox в левом верхнем углу – это настоящая консоль.

В центре экрана – то, ради чего всё затевалось. Эмулятор QPE версии 1.3, июнь 2001 года. В целом, я бы сказал, что лишь немногим хуже первых версий Android или iOS. И уж точно на голову выше того, что спустя 7 лет могла исполнить ОС Symbian, хоть в варианте S40 (Nokia), хоть в варианте UIQ (Motorola и Sony-Ericsson).

>>> Просмотр (3840x2160, 379 Kb)

Всем здравствуйте.

Закончил подбор «железа» для Solaris 8 на x86 (SPARC-машины тоже есть, но сейчас речь не о них).

Долго промучился с настройкой карты Sound Blaster 16 (CT2230), но так и не добился возможности вывода 16-разрядного PCM-звука. В результате была куплена плата AWE64 (CT4380), которая была опознана системой и сразу заработала.

Результат на снимке.

«Железо»:

• Intel Celeron 500 MHz,
• материнская плата ECS (EliteGroup) P6VAP-A+ на чипсете VIA,
• память: 1.5 ГБ (3x512 МБ),
• видеоплата: Matrox G450 PCI DVI (единственная, которая в связке с сервером Xsun смогла «выдать» 1600x1200x32bpp – перепробовал множество разных «матроксов» от G400 до G550 и ATI Rage 128),
• сетевая плата 3Com 3c509,
• Sound Blaster AWE64 (CT4380).

>>> Просмотр (1600x1200, 681 Kb)

Решил открыть в последнем (4.14) Eclipse CDT проект на C, использующий Makefile в свободной форме.

Что ж, проиндексировалось и открылось всё весьма быстро и, как видно, сам Eclipse в памяти занимает меньше 1 ГБ. И да, я могу вручную (ни о каком автоопределении целей, как это умеет remake, речи не даже идёт) добавить произвольные цели make (make targets) и собрать их (см. окно «Build Targets» справа).

Но на этом плюсы заканчиваются.

Eclipse не обрабатывает Makefile’ы и не строит базу данных компиляции в процессе создания проекта и потому индексирует тупо всё, что попадётся под руку. Это значит, что список включённых в проект файлов (часть модулей же обычно исключена из .config), равно как и #define’ы, ему априори неизвестны, и ни о каком точном рефакторинге говорить нельзя.

Более того, часть (включённого) кода в редакторе «сияет красным», и мне сообщают об ошибках, которых нет. Так, на снимке на 324-й строке fs/btrfs/async-thread.c Eclipse не может определить тип переменной work, хотя и ежу понятно, что это тип struct btrfs_work *, и этот тип определён в лежащем рядышком хедере. При попытке навигации к объявлению переменной work (хотя это локальная переменная в btrfs_work_helper()) мне предлагается 100500 кандидатов, разбросанных по всему проекту (диалог Open Declaration).

Вердикт – текстовый редактор, не более. Я, как давний пользователь и поклонник Eclipse, реально разочарован.

Несколько обязательных комментариев:

• WM – WindowMaker
• Тема оформления GTK3 – Greybird. К сожалению, только в «штатных» темах Adwaita, Greybird и Numix Eclipse выглядит удовлетворительно (в силу того, что разработчики SWT сделали ряд «хаков» для поддержки этих конкретных тем оформления), хотя, напр., поля ввода по-прежнему выглядят гигантскими. Сами разработчики рекомендуют попробовать отключить вышеупомянутые «хаки» (-Dorg.eclipse.swt.internal.gtk.noThemingFixes, см. bug 527729) и включить Clearlooks-Phénix, но, на мой взгляд, там работы ещё непочатый край: кнопки панели инструментов становятся раза в полтора больше и «уезжают» вправо.
• Да, ШГ. Да, «кровь из глаз». Да, я всё это уже не раз слышал.

>>> Просмотр (1920x1200, 146 Kb)

Долго пытался заставить GTK+ версии 3 выглядеть согласованно с темой Raleigh из GTK+ 2.0 (разработчики бросили её обновлять давным-давно, и в варианте по умолчанию она непригодна для использования), пока не наткнулся на вот эту годноту.

На снимке — meld, gedit и evince.

Не то, чтобы я стал активно переползать на третью версию с GTK+ 2.0 и Qt 5 (свят, свят), но теперь хотя бы не плююсь при её виде.

Плюсуйте проект на Гитхабе — автору темы наверняка будет приятно.

>>> Просмотр (3840x1200, 449 Kb)

Читал тут давеча стандарт (XLFD Conventions, 1989 года, автор — Джим Флауэрс (Jim Flowers) из DEC) и обнаружил для себя новое.

Оказывается, в поле ptSz можно указать не просто размер шрифта в десятках пунктов (120 == 12pt), а настоящие коэффиценты матрицы (в виде [x1 x2 y1 y2]) для аффинного преобразования символов. При этом пресловутое скалярное значение 120 соответствует матричным коэффициентам [12.0 0 0 12.0] (единичная матрица, умноженная на размер в пунктах; коэффициенты с плавающей точкой; отрицательные значения задаются через тильду (~) вместо минуса (-), поскольку минус является разделителем полей в XLFD).

Применение? Элементарно. Например, так можно получить курсив из обычного шрифта. Или обратный курсив (reverse oblique).

Но можно и совсем упороться и тупо перевернуть символы (и получившийся текст, при определённой сноровке, даже можно прочитать).

А Xft или FreeType так умеет? =)

>>> Просмотр (1920x1080, 148 Kb)

Однажды на работе было особенно тоскливо, и решил я собрать эту штуку (а заодно и посмотреть на API).

ИМХО, для десктопа пока не годится (emacs, screen или, прости господи, tmux на экзотических терминалах куда стабильнее), но фичи же! Перекрывающиеся окна! Окна переменного размера! Поддержка Unicode! Расширяемое API!

Что примечательно, проект не делит ни строчки исходного кода ни с одним из форков оригинального Turbo Vision, т. е. велосипед был честно изобретён с нуля.

P.S. Проект уже давно переехал с SF (ещё скриншоты) на GitHub (завалите автора pull-реквестами).

P.P.S. Звиняйте за шрифты и обоину!

>>> Просмотр (1920x1080, 82 Kb)

В связи с выходными и двухдневным периодом безделья было решено проверить работоспособность двух машин Sun Blade 100. На одной батарейка NVRAM-чипа сдохла, так что теперь или вооружаться надфилем/паяльником, или в очередной раз заказывать из-за океана — а вот вторая машина таки завелась.

( читать дальше... )

>>> Просмотр (800x600, 49 Kb)

... или как оно выглядело 10 лет назад.

P. S. Установка, вроде, прошла успешно.

>>> Просмотр (1600x1200, 64 Kb)

Рабочее место. Только справа картинку пришлось обрезать, поэтому окно xoswiev почти не видно.

В левом скрине -- роза и nedit,
в правом -- xdaliclock от Jamie Zawinski, mplayer и xps.

Там ещё есть gvim, eclipse и emacs, но они иконизированы.

Закос, понятное дело, делался под Solaris CDE.

>>> Просмотр (2046x1024, 111 Kb)