LINUX.ORG.RU

The Stump Window Manager 0.9.0

 ,


0

0

Stumpwm - это простой, управляемый клавиатурой менеджер окон для x11, полностью написанный на Common Lisp. Stumpwm имеет минимальные возможности для визуальной настройки.
В новой версии добавлена поддержка виртуальных рабочих столов, прогресс-бара, цветного текста, Xinerama, XRandR, увеличена стабильность.

Скриншоты: http://www.nongnu.org/stumpwm/screens...

>>> Сайт Stumpwm

Ответ на: комментарий от feanor

Брэйнфак - игрушки. Из его вариантов есть ещё brainfork - многопоточный, есть Ook! - код веселее. А из других - Befunge и Malbolge жгут. Вот на Befunge я хочу ВМ увидеть ). Только нужно как-то ввод и вывод привязать к такой проге, например прослойку + кормить всё башу.

ChALkeR ★★★★★
()

Убойная вещь. Авторы те же, что и ratpoison писали.

mv ★★★★★
()
Ответ на: комментарий от anonymous

> Отстой. FVWM наше всио.

StumpWM можно на ходу, не останавливая, хоть весь переписать. FVWM - отстой для латентных кдешников/гномеров.

mv ★★★★★
()

Вещь хорошая, в себе :)

catap ★★★★★
()
Ответ на: комментарий от ChALkeR

> Брэйнфак - игрушки. Из его вариантов есть ещё brainfork - многопоточный, есть Ook! - код веселее. А из других - Befunge и Malbolge жгут. Вот на Befunge я хочу ВМ увидеть ). Только нужно как-то ввод и вывод привязать к такой проге, например прослойку + кормить всё башу.

Lazy-K всех заруливает.

anonymous
()
Ответ на: комментарий от anonymous

А в пределе все к кедам стремится

anonymous
()

Угу. Только у меня он регулярно "замерзает". Беттс советовал пересобрать под Clisp, но это еще Clisp надо обновлять до 2.42...

mind
()
Ответ на: комментарий от mind

Проблема в sbcl с обработкой событий. Я в src/runtime/interrupt.h увеличил MAX_INTERRUPTS до 4096, пересобрал sbcl. После этого stumpwm вообще перестал в дебаггер вылетать ("замерзать").

mv ★★★★★
()
Ответ на: комментарий от mv

Нет, у меня это что-то другое было. В дебаггер он не вылетал, просто переставал реагировать на события X. mode-line не обновлялась. Через ssh захожу -- sbcl работает, а stump -- нет. Я сначала на threaded SBCL грешил, пересобрал без threads, но не помогло.

mind
()
Ответ на: комментарий от mind

> Нет, у меня это что-то другое было. В дебаггер он не вылетал, просто переставал реагировать на события X.

Нет, у тебя было именно то, про что я говорил. При привышения max nested interrupts происходит вход в LDB (low level debugger). Т.к. ты с LDB общаться не можешь (консоли нет), то выглядит это как "заморозка". Почитай мейллист sbcl-devel за январь.

mv ★★★★★
()
Ответ на: комментарий от mv

Кстати, по поводу отсутствующей консоли -- я пробовал пускать stump из-под sbcl, работающего в slime. Если я правильно понял, то я должен был бы увидеть ldb prompt, если бы дело было в этом?

Я о своей проблеме писал в stumpwm-devel:

http://www.mail-archive.com/stumpwm-devel@nongnu.org/msg00406.html

и

http://www.mail-archive.com/stumpwm-devel@nongnu.org/msg00407.html

Вот ответ Беттса:

http://www.mail-archive.com/stumpwm-devel@nongnu.org/msg00415.html

mind
()
Ответ на: комментарий от mind

>Угу. Только у меня он регулярно "замерзает". Беттс советовал пересобрать под Clisp, но это еще Clisp надо обновлять до 2.42...

Насколько я знаю (точно не следил, но видел), Беттс сказал, что просто он какие-то патчи сделал для CLISP в подсистему new-clx, чтобы stumpwm запускался. Но он, например, наверняка не знает, что telent-clx, который используется при компиляции с SBCL, уже работает на CLISP. У меня на CLISP 2.41 работает McCLIM с этим CLX. Но вот stumpwm я вообще ни разу не пробовал. И, наверное, пробовать не буду, потому что мне концепции a-la Ratpoison не нравятся.

CLISP должен быть собран без опций new-clx и mit-clx. По умолчанию он так и собирается, если специально не указать.

Пропатченный под CLISP CLX можно взять тут:

darcs get http://common-lisp.net/~crhodes/clx

Если будет время, можешь попробовать.

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

Спасибо, Zubok, буду иметь в виду. Если sbcl, только что пересобранный по подсказке mv, не поможет, попробую clisp.

mind
()
Ответ на: комментарий от mind

Разница между new-clx и telent-clx в том, что первый написан на Си, а второй -- на CL. Библиотека new-clx есть только для CLISP (входит его source tree), и по идее должна быть побыстрее. Но с new-clx не работает McCLIM и много еще чего. И я даже не знаю, кто сопровождает эту штуку. Счастье, конечно, что спецификация CLX существует в весьма хорошо документированном виде. Видимо, есть какие-то прорехи в реализации. И только у Беттса дошли руки что-то там дописать, чтобы запустить stumpwm. Вот как раз в changelog clisp 2.42

NEW-CLX module now supports Stumpwm <http://www.nongnu.org/stumpwm/>;. Thanks to Shawn Betts <sabetts@vcn.bc.ca>.

Zubok ★★★★★
()
Ответ на: комментарий от AsphyX

> Да что же все эти tiling-wm'ы такие страшные...

Хороший tiled wm не должно быть видно - только окна запущенных программ.

mv ★★★★★
()
Ответ на: комментарий от Deleted

>Даешь WM на bash'е!!! )

Ну, если ImageMagick заюзать, то почему бы и нет:)

Led ★★★☆☆
()
Ответ на: комментарий от mv

> Проблема в sbcl с обработкой событий. Я в src/runtime/interrupt.h увеличил MAX_INTERRUPTS до 4096, пересобрал sbcl. После этого stumpwm вообще перестал в дебаггер вылетать ("замерзать").

Stranno. Nikogda ne bylo takoy problemy. sbcl sobran s sb-thread, stumpwm iz git HEAD.

ska
()
Ответ на: комментарий от ska

> Stranno. Nikogda ne bylo takoy problemy. sbcl sobran s sb-thread, stumpwm iz git HEAD.

На десктопном Xeon 5110 (2x 1600 MHz) + Fedora-7/x86 валится от нескольких секунд до 2 минут. На ноутбучном Core2Duo T7500 (2x 2200 MHz) + Fedora-8/x86-64 валится очень редко, причём, Xeon работает всегда на 1.6 ГГц, а ноутбучный почти всегда на 800 МГц. У меня составилось мнение, что SBCL от дополнительных 8 машинных регистров в 64-битном режиме в плане скорости сильно выиграл.

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.