Отладочная плата под AVR-8
Всем привет.
$subj
Собственно остановился пока на STK500. Может, кто ещё чего толкового подскажет?
Всем привет.
$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 софт для моделирования цифровых логических цепей изо всяких там защёлок, триггеров, мультиплексоров и т.п.?
Всем привет. В общем такая схема: - запускаю в терминале процесс в фоновом режиме $ ./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,
хотя даже при этом условии как-то всё происходит странно.
Если кто-то в этом что-то понимает, поясните, плиз.| ← предыдущие | следующие → |