Сабж.

Начал изучение LISP и не понимаю, что происходит при работе setf в моём случае. Пример упрощённый, в реальности всё несколько сложнее.

Есть код:

(dotimes (i 2)
  (let ((vec (make-array 0 :fill-pointer 0 :adjustable t)))
    (format t "Vector before: ~a~%" vec)
    (format t "Pushing: ~a~%" '(1 1))
    (vector-push-extend '(1 1) vec)
    (format t "Vector after push: ~a~%" vec)
    (setf (elt (aref vec 0) 1) 10)
    (format t "Vector after setf: ~a~%" vec)
    (vector-push-extend '(1 1) vec)
    (format t "Vector after push 2: ~a~%" vec)))

При запуске выдаёт следующее.

$ sbcl --script cl.cl 
Vector before: #()
Pushing: (1 1)
Vector after push: #((1 1))
Vector after setf: #((1 10))
Vector after push 2: #((1 10) (1 1))
Vector before: #()
Pushing: (1 1)
Vector after push: #((1 10))
Vector after setf: #((1 10))
Vector after push 2: #((1 10) (1 1))

В конце цикла я модифицирую setf'ом первый элемент вектора. Во второй итерации цикла этот элемент оказывается уже модифицированным, хотя вектор другой, итерация другая и элемент я добавляю заново.

Выглядит так, словно на самом деле модифицируется _аргумент_ первого vector-push-extend. Но как он получает доступ к аргументу? Разве каждый раз при записи '(1 1) не должен создаваться _новый_ список из двух единиц? А если не должен, то почему не модифицируются списки '(1 1), передаваемые в format и во второй vector-push-extend?

Где об этом можно вообще почитать? Смотрел в PCL и книжку Грехема, но там о деструктивных операциях с гулькин нос. К тому же, проблема вроде как даже не в деструктивных операциях, а в принципе работы компилятора/интерпретатора.

На фоне отказа некоторых форков некоторых дистрибутивов от поддержки x86 и предложений отказаться от поддержки ядром linux технологии Ethernet, многопользовательского режима, многомониторных конфигураций и архитектуры x86, от поддержки популярной 32битной платформы отказывается очередной ранее хороший дистрибутив - CRUX.

Тенденция, однако. Остаётся одна надежда - на слаку.

http://lists.crux.nu/pipermail/crux/2012-August/009768.html

Ъ: «CRUX 2.8 x86 will be the final 'official' x86 release of CRUX before switching official support to the x86_64 architecture».

Меня как обладателя NVIDIA 8600GTS в конец достало, что после выхода из иксов монитор выключается, и работать в консоли (в смысле, выключать компьютер) приходится вслепую. На форуме производителя куча багрепортов, но проблема пока не решена. Пока откатился на 3.0.33 и 290.10, посмотрим будут ли проблемы на такой связке.

Начитавшись жизнерадостных отзывов о скорости 2D-графики и радужных форониксовских тестов, решил наконец попробовать nouveau.

В итоге оказалось, что nouveau сливает блобу в 3-5 раз:

• glxgears выдаёт 3 000 FPS вместо 13 000 FPS (при том, что в последнем случае проц нагружен на 100%, а в первом меньше чем на 50%, так что производительность nouveau упирается именно в работу с картой),
• speed-dreams-2 выдаёт 50-70 FPS вместо 150-250 FPS (при одинаковых настройках)
• time cat notes.txt в uxterm отрабатывает за 170 мс вместо 40 мс (после нескольких лет на блобе, разница ощутима на глаз)

xf86-video-nouveau и Mesa брал из репозитория с месяц назад, ядерный модуль - встроенный в linux-3.4.1.

Знатоки, подскажите, так и должно быть? Или у меня руки кривые и надо что-нибудь покрутить? Я правильно понимаю, что смысла пробовать модуль ядра из репозитория нет, т.к. в ядре последняя стабильная версия?

До взлома на ftp://ftp.kernel.org хостилось множество тарболов (man-pages, util-linux и многие другие). Судя по PKGBUILD'ам арча теперь они все разъехались по разным сайтам вроде man7.org.

Это временное явление, и ftp://ftp.kernel.org ещё не полностью восстановлен (а когда восстановят, вернут ли все эти проекты обратно на ftp://ftp.kernel.org?), или теперь так и будет, и ftp://ftp.kernel.org можно считать полностью восстановленным?

P.S. И только у меня на kernel.org отображается последняя версия 3.0.4 и 3.1-rc4?

Давно ещё смотрел фильм, зарубежный, снят в районе 1990-2000 годов (не позже, но возможно ещё раньше).

Чем-то похож на «достучаться до небес», «трасса 60», «бойцовский клуб».

По сюжету чела бросает девушка из-за того, что он не слишком крут для неё, слишком мягок, что «она уйдёт от него, а он ей даже вслед ничего грубого не скажет», потом с ним ещё какие-то приблемы происходят. Однажды кто-то ему говорит нечто вроде «никогда не давай себя в обиду, всегда мсти». Он начинает убивать тех, кто портил ему жизнь, потом приходит к ней, говорит «останься со мной, я изменился, стал другим, таким, как ты хотела». Она ему не верит, посылает его, и он её убивает.

Уже в конце фильма в какой-то перестрелке его убивают - он в ненужный момент перестрелки высовывает голову из-за какого-то ящика - кто-то (вроде брат) кричит ему, чтоб убрал голову, но не успевает.

Затем он приходит в какой-то бар, там сидят два старика, которые (как оказывается позже) решают, кто идёт в рай, а кто в ад, и ещё двое - шулер и другая девушка.

Шулера они отправляют в ад, за то, что он только что мухлевал и обыграл их, главного героя отправляют в рай, т.к. один из стариков лично знает его отца. На самом деле в рай должна была попасть девушка, и когда оказывается, что она в ад, кричит «это же я должна была в рай попасть», но один старик, говорит «а ты однажды изменила своему парню, так что в ад» (т.е. он «протолкнул» главного героя в рай по блату).

--

Один знакомый сказал, что припоминает что-то такое, и фильм, скорее всего, или финский, или шведский, или норвежский.

Вопрос пользователям вима: как вы печатаете текст в виме?

Периодически пользуюсь вимом, и понял, что по функционалу вим на голову выше большинства (если не всех) других редакторов, перемещение hjkl удобнее стрелочек и... когда приходится править код или тексты в mcedit, кажется, что редактор мешает мне это делать вместо того, что помогать. В общем, привык я к виму, видимо. Но...

Местами появляется какая-то некомфортность, что ли, из-за того, что часто приходится переключаться между режимами. Если я бОльшую часть времени провожу в правке или просмотре кода, то особых проблем нет. Но как только начинаю писать что-то с нуля, возникают проблемы типа описанной ниже.

Допустим я написал «аытомобиль» и обнаружил ошибку. Что делать?

1. Идеология vi предполагает ввод <Esc>blrвea, что имхо длинновато и неинтуитивно для такой простой операции.
2. Идеология блокнота предполагает <Ctrl-Left><Right><Del>в<Ctrl-Right>, что более интуитивно (и вим такое позволяет),
3. Можно дописать текст до конца с ошибками, а потом пройтись спелчекером по всему тексту и исправить ошибки (слишком накладно, если я поменял всего 2 строки в 30-килобайтном файле).
4. какие ещё варианты?

Возникает ли что-то подобное у вас, и как _вы_ решаете такие проблемы?

New drivers that will show up in the .32 kernel release:
- ...
- Microsoft Hyper-V drivers. Over 200 patches make up the massive cleanup effort needed to just get this code into a semi-sane kernel coding style ... the Microsoft developers seem to have disappeared, and no one is answering my emails ...

Источник: http://lkml.org/lkml/2009/9/3/3

Давно хотелось выбрать наименее ресурсоёмкий графический (т.е. lynx, links и w3m не подходят) браузер, ибо памяти всего 2 гига, и расходовать её впустую не хочется.

Кроме того, было интересно, насколько легковесны браузеры, выдаваемые гуглом по запросу «lightweight browser» (arora и midori).

Результаты тестов приведены ниже. Показаны значения, выдаваемые командой top (объём занимаемой памяти в мегабайтах). Сортировка в первом случае шла по VIRT(N), во втором - по RES(N).

by VIRT(N)      VIRT(1) RES(1)  VIRT(N) RES(N)
arora           669     64      688     86
midori          652     51      672     73
surf            576     41      -       -
firefox         562     72      592     99
konqueror4      468     51      494     77
opera10         370     57      386     72
opera           342     62      350     81
konqueror3      289     52      310     73
netsurf         228     33      257     62

by RES(N)       VIRT(1) RES(1)  VIRT(N) RES(N)
firefox         562     72      592     99
arora           669     64      688     86
opera           342     62      350     81
konqueror4      468     51      494     77
konqueror3      289     52      310     73
midori          652     51      672     73
opera10         370     57      386     72
surf            576     41      -       -
netsurf         228     33      257     62

Тесты проводились в два этапа:

1. VIRT(1) и RES(1) - отображение главной страницы хабра (я всегда использовал оперу, и в ней хабр - один из самых медленноработающих ресурсов, поэтому выбрал его).

2. VIRT(N) и RES(N) - открытие во вкладках нескольких страниц (главная страница хабра, kernel.org, тема на хабре, страница темы на ЛОРе - во всех браузерах открывались одни и те же страницы).

Замечания:

1. NetSurf не поддерживает JavaScript,

2. surf - браузер проекта suckless.org, основанный на WebKit. Не поддерживает работу с закладками, поэтому значения (N) отсутствуют. Исходник браузера минимальный, и этот браузер использовался как оценка «минимальных требований» вебкита к отображению страницы.

3. Никаких плагинов к firefox не стоит.

4. Тестировалось на pure-x86_64-машине с 2Гб памяти, указанный ниже софт (кроме опер) собирался с флагами "-Os -march=k8-sse3".

5. Версии софта:

arora-0.7.1
firefox-3.5.2
midori-0.1.9
konqueror4-4.2.1
konqueror3-3.5.10
netsurf-r9500
opera-9.64.gcc4.shared.qt3.x86_64
opera10-10.00-4453.gcc4-qt4.x86_64
surf-20090829

WebKit-r46919
qt3-3.3.8
qt4-4.5.2

Выводы:

1. Опера выглядит хорошо, особенно по объёму виртуальной памяти (VIRT).

2. Если на 10 сайтах написать, что определённый браузер (arora, midori) «легковесен», легковесным он от этого не станет.

3. Firefox не так плох относительно других, как я думал раньше.

4. konqueror4 всё же деградировал по сравнению с konqueror3 (камень в огород четвёртых кед).

Традиционно для запуска Java-приложений использовался Sun JDK.

Но теперь мы хотим полностью отказаться от бинарного Sun JDK, соберём из исходников OpenJDK. Для этого: 1. устанавливаем бинарный Sun JDK 2. собираем OpenJDK

Но поскольку мы хотим полностью отказаться от бинарного Sun JDK, для сборки OpenJDK будем использовать IcedTea. Для этого: 1. устанавливаем бинарный Sun JDK 2. собираем apache-ant 3. собираем IcedTea 4. собираем OpenJDK

Вопрос: на[ЦЕНЗУРА] делать шаги 2, 3, 4, если уже после шага 1 есть полноценное рабочее Java-окружение?

В опции -mpreferred-stack-boundary=N какое N лучше всего использовать, если я собираю Gentoo 2004.3 (кто не знает - то есть я собираю ВСЮ систему целиком сам) под AthlonXP 2500+ (Barton). Проверено на практике, что 4 (значение по умолчанию) лучше, чем 2. Не будет ли 3 полезнее для уменьшения перезагрузок кэша, но, с другой стороны, не получится ли больше тормозов при обращении к данным, не выравненным на 16 байт (т.е. не лучше ли использовать -mpreferred-stack-boundary=3)?