Всем привет.

$subj

Собственно остановился пока на STK500. Может, кто ещё чего толкового подскажет?

>>>

$subj

Может кто встречал? Интересуют по крайней мере "Архитектура компьютера" и "Современные операционные системы".

>>>

Всем привет.

Собственно сабж, работать не можется, повторяем репертуар! :) Кто-нибудь с ЛОРа идёт?

>>>

Всем привет.

Ищу туториал, по программированию на asm под x86_64. Просто перечень основных отличий от ia32 подойдёт. Что-то я не сходу нагуглил.

>>>

Народ, подскажите, как в xfce переназначить горячии клавиши переключения раб. столов и прочее, а то я что-то туплю?

>>>

Сабж.

Гном и сопутствующее не интересны, интересно, стабильна ли базовая система.

>>>

Народ, кто-нибудь пробовал прикрутить compiz-fusion к xmonad или чему-то подобному? Меня собственно интересует только эффект кэширования содержимого окна, свойственный compiz-fusion (всякие глючные xcompmgr так не умеют), чтобы при переключении между раб. столами не было видно постоянных перерисовок дерева контролов. Есть смысл заниматься?

>>>

Всем привет.

Подскажите, можно ли в xmobar сделать кликабельные лэйблы воркспэйсов? Доку пролистал - не нашёл. Хотя на каком-то скрине видел...

>>>

Всем привет.

Почитываю на досуге как дополнение к "Real World Haskell" книгу Душкин Р.В. "Справочник по языку Haskell". Имею вопрос по замыканиям.

Несколько цитат:

"Замыкания или локальные определения - один из механизмов ФП, который предназначен для оптимизации определения функций",
"Из-за детерминизма, свойственного ФП, значение локальных определений выч-ся один раз, и оно не может быть изменено в рамках текущего выч. процесса.
Это свойство и используется для оптимизации, посколько локальным определением можно обозвать нечто в теле функции, что выч-ся несколько раз.
Так как в любом случае при вычислениях будут получены одинаковые рез-ты, локальное определение позволяет выполнить вычисления единожды".

В качестве подтверждения приводится пример стандартной ф-ии lines:

lines "" = []
lines s  = let (l, s') = break ('\n' ==) s
           in l : case s' of
                    []      -> []
                    (_:s'') -> lines s''

Мне непонятно, что именно здесь может быть вычислено единожды и что понимается под "вычислительным процессом", ведь каждый раз аргументы у lines меняются.

Помогите привести сознание в порядок. Спасибо заранее. :)

>>>

Всем привет.

В книге RealWorldHaskell встретил такой вот стиль кода:

data Customer = Customer {
      customerID      :: Int
    , customerName    :: String
    , customerAddress :: Address
    } deriving (Show)

Как по мне, расположение запятых несколько удручает.
И выравнивание '::' руками слишком трудоёмко.
Может есть какие-то оффициальные рекомендации по стилю Haskell кода?
К примеру, если написать вот так:

data Customer = Customer {
      customerID :: Int,
      customerName :: String,
      customerAddress :: Address
    } deriving (Show)

не закидают какашками?

>>>

Всем привет.

Подскажите, где взять полный список кодов городов, которые используются на gismeteo.ru? Можно онлайн. А то раньше бот забмитил на гисметео форму, парсил результат и получал код, а теперь они там размётку поменяли, лень разбираться.

>>>

Всем привет.

Подскажите, есть ли под GNU/Linux софт для моделирования цифровых логических цепей изо всяких там защёлок, триггеров, мультиплексоров и т.п.?

>>>

Посоветуйте книгу/доку по иксам (концепция, API и т.п.).

>>>

Всем привет.

В общем такая схема:
- запускаю в терминале процесс в фоновом режиме
  $ ./main &
  UID        PID  PPID  PGID   SID  C STIME TTY          TIME CMD
  tvaroh    7722  7696  7722  7696  0 03:06 pts/2    00:00:00 ./main

- при наступлении определённого события (появления данных в fifo) этот процесс должен написать в stdout сообщение
- закрываю терминал и отправляю в fifo сообщение
- проверяю pgrep main - процесс всё ещё выполняется, хотя вроде как ему должен был отправиться сигнал SIGTTOU (никаких перехватов сигналов в коде нету)
- смотрю вывод ps:
  UID        PID  PPID  PGID   SID  C STIME TTY          TIME CMD
  tvaroh    7722     1  7722  7696  0 03:06 ?        00:00:00 ./main

PPID сменился на 1 (init).

Собственно вопрос: почему так происходит?

>>>

Сабж. Подскажите репозитарий, желательно сборки с убунтушными патчами.

>>>

Всем привет.

В gnome-system-monitor-2.22 в закладке Resources появились эдакие диаграммы нагрузки на процессор, потребления памяти и сетевой активности. Рисует это всё, насколько я понимаю, cairo. Так вот, при этом "рисовании" почти на 100% забивается проц и перемещение окошка мышкой происходит рывками. Такое ощущение, что иксы от этого входят в ступор.

Спрашивается: нафига такая радость надо? У меня одного так?

>>>

Всем привет.

Посоветуйте DE-независимый терминал, у которого нет проблем с юникодом, по возможности табы и возможность сменить шрифт. :)

Почти по всем характеристикам вроде бы подходит xfce4-terminal, но после gnome-terminal им пользоваться невозможно. Постоянно какие-то левые мерцания, ужасный ресайз и т.д.

>>>

Всем привет.

$ cat .gtkrc-2.0
gtk-theme-name = "Human-Murrine"
gtk-icon-theme-name = "Human"
gtk-font-name = "Tahoma 7"
gtk-xft-antialias = 1
gtk-xft-dpi = 96
gtk-xft-hinting = 1
gtk-xft-hintstyle = "hintfull"
gtk-xft-rgba = "rgb"
gtk-toolbar-style = GTK_TOOLBAR_BOTH_HORIZ
gtk-key-theme-name = "Emacs"

Всё работает кроме сглаживания, шрифты по сравнению с другими GTK+ приложениями просто кошмарные.
Вроде бы и сглаженные, но как-то криво.
Достаточно запустить gnome-settings-daemon, как всё становится на свои места.

Есть ли противоядие?

>>>

Всем привет. Пишем простейшее приложение на GTK+:

#include <gtk/gtk.h>

int
main (int argc, char *argv[])
{
  GtkWidget *window;

  gtk_init (&argc, &argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  g_signal_connect (G_OBJECT (window), "destroy",
                    G_CALLBACK (gtk_main_quit), NULL);
  gtk_widget_show (window);

  gtk_main ();
  return 0;
}

Собираем: gcc -g -O0 -Wall -pedantic `pkg-config --cflags --libs gtk+-2.0` main.c -o main

Натравливаем на него valgrind:

Invalid read of size 4
==26978==    at 0x4015209: (within /lib/ld-2.7.so)
==26978==    by 0x4005C69: (within /lib/ld-2.7.so)
==26978==    by 0x4007A97: (within /lib/ld-2.7.so)
==26978==    by 0x4011543: (within /lib/ld-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x4010F5D: (within /lib/ld-2.7.so)
==26978==    by 0x4731291: (within /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x4731454: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x470B186: __nss_lookup_function (in /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x470B29F: (within /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x470D075: __nss_passwd_lookup (in /lib/tls/i686/cmov/libc-2.7.so)
==26978==  Address 0x4bc8284 is 36 bytes inside a block of size 38 alloc'd
==26978==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==26978==    by 0x4008031: (within /lib/ld-2.7.so)
==26978==    by 0x4011543: (within /lib/ld-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x4010F5D: (within /lib/ld-2.7.so)
==26978==    by 0x4731291: (within /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x4731454: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x470B186: __nss_lookup_function (in /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x470B29F: (within /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x470D075: __nss_passwd_lookup (in /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x46B7B72: getpwnam_r (in /lib/tls/i686/cmov/libc-2.7.so)
==26978== 
==26978== Invalid read of size 4
==26978==    at 0x4015237: (within /lib/ld-2.7.so)
==26978==    by 0x4005C69: (within /lib/ld-2.7.so)
==26978==    by 0x4007A97: (within /lib/ld-2.7.so)
==26978==    by 0x400BC16: (within /lib/ld-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x400BDF9: (within /lib/ld-2.7.so)
==26978==    by 0x40115A3: (within /lib/ld-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x4010F5D: (within /lib/ld-2.7.so)
==26978==    by 0x4731291: (within /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x4731454: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.7.so)
==26978==  Address 0x4bc85cc is 28 bytes inside a block of size 31 alloc'd
==26978==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==26978==    by 0x4008031: (within /lib/ld-2.7.so)
==26978==    by 0x400BC16: (within /lib/ld-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x400BDF9: (within /lib/ld-2.7.so)
==26978==    by 0x40115A3: (within /lib/ld-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x4010F5D: (within /lib/ld-2.7.so)
==26978==    by 0x4731291: (within /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x400D5D5: (within /lib/ld-2.7.so)
==26978==    by 0x4731454: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.7.so)
==26978==    by 0x470B186: __nss_lookup_function (in /lib/tls/i686/cmov/libc-2.7.so)

-- и ещё много похожих ругательств --

==27164== ERROR SUMMARY: 10 errors from 9 contexts (suppressed: 99 from 1)
==27164== malloc/free: in use at exit: 253,147 bytes in 3,181 blocks.
==27164== malloc/free: 10,472 allocs, 7,291 frees, 706,786 bytes allocated.
==27164== For counts of detected errors, rerun with: -v
==27164== searching for pointers to 3,181 not-freed blocks.
==27164== checked 582,764 bytes.

Откуда столько ошибок? Development branch?

>>>

Всем привет. Есть вот такая програмка, демонстрирующая поведение GTK+ при изменении размера контейнера (в данном случае GtkWindow):

#include <gtk/gtk.h>

static void
window_resize_cb (GtkWidget *window, GtkAllocation *allocation, gpointer data)
{
  g_message ("window: new size %dx%d", allocation->width, allocation->height);
}

static void
button_resize_cb (GtkWidget *window, GtkAllocation *allocation, gpointer data)
{
  g_message ("button: new size %dx%d", allocation->width, allocation->height);
}

static void
window_size_request_cb (GtkWidget *window, GtkRequisition *requisition, gpointer data)
{
  g_message ("window: request size %dx%d", requisition->width, requisition->height);
}

static void
button_size_request_cb (GtkWidget *window, GtkRequisition *requisition, gpointer data)
{
  g_message ("button: request size %dx%d", requisition->width, requisition->height);
}

int
main (int argc, char *argv[])
{
  GtkWidget *window, *button;

  gtk_init (&argc, &argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  gtk_container_set_border_width (GTK_CONTAINER (window), 10);
  g_signal_connect (G_OBJECT (window), "destroy", G_CALLBACK (gtk_main_quit), NULL);

  button = gtk_button_new_with_label ("some label");
  gtk_container_add (GTK_CONTAINER (window), button);

  g_signal_connect (G_OBJECT (window), "size-allocate",
		    G_CALLBACK (window_resize_cb), NULL);
  g_signal_connect (G_OBJECT (button), "size-allocate",
		    G_CALLBACK (button_resize_cb), NULL);
  g_signal_connect (G_OBJECT (window), "size-request",
		    G_CALLBACK (window_size_request_cb), NULL);
  g_signal_connect (G_OBJECT (button), "size-request",
		    G_CALLBACK (button_size_request_cb), NULL);

  gtk_widget_show_all (window);

  gtk_main ();
  return 0;
}

Собираем так: gcc -Wall -pedantic `pkg-config --cflags --libs gtk+-2.0` resizing.c -o resizing

Запускаем:

.$ ./resizing 
** Message: button: request size 74x29
** Message: window: request size 94x49
** Message: button: new size 74x29
** Message: window: new size 94x49

-- здесь вопросов нету. Теперь делаем разовый ресайз окна средствами WM --

** Message: window: request size 94x49
** Message: button: new size 84x29
** Message: window: new size 104x49
** Message: window: request size 94x49
** Message: window: new size 104x49

Вот здесь начинаются вопросы.
Насколько мне известно, для вычисления новых размеров компонентов внутри контейнера,
контейнер рекурсивно запрашивает *желаемые* размеры "детей" (структура GtkRequisition). Это стадия 1.
Потом происходит фактическое выделение размеров (структура GtkAllocation). Это стадия 2.
В нормальных условиях, если свойство "resizable" окна не установлено в FALSE, то реальные размеры компонентов будут такими, какими они были на стадии 1.

Мы же видим следующее:
> ** Message: window: request size 94x49
Окно запрашивает старый размер
> ** Message: button: new size 84x29
Кнопка получает новый размер
> ** Message: window: new size 104x49
Окно получает новый размер
> ** Message: window: request size 94x49
Окно запрашивает старый размер и ...
> ** Message: window: new size 104x49
... получает новый.

Какая-то ерунда получается.
У меня есть подозрение, что я как-то неправильно полагаюсь на сигналы size-request и size-allocate,
хотя даже при этом условии как-то всё происходит странно.

Если кто-то в этом что-то понимает, поясните, плиз.

>>>