В каких языках программирования есть реализация realtime gc?

PAUSE
Spin Loop Hint

Improves the performance of spin-wait loops. When executing a "spin-wait loop," a Pentium 4 or Intel Xeon processor suffers a severe performance penalty when exiting the loop because it detects a possible memory order violation. The PAUSE instruction provides a hint to the processor that the code sequence is a spin-wait loop. The processor uses this hint to avoid the memory order violation in most situations, which greatly improves processor performance. For this reason, it is recommended that a PAUSE instruction be placed in all spin-wait loops.

An additional function of the PAUSE instruction is to reduce the power consumed by a Pentium 4 processor while executing a spin loop. The Pentium 4 processor can execute a spin-wait loop extremely quickly, causing the processor to consume a lot of power while it waits for the resource it is spinning on to become available. Inserting a pause instruction in a spin-wait loop greatly reduces the processor's power consumption.

This instruction was introduced in the Pentium 4 processors, but is backward compatible with all IA-32 processors. In earlier IA-32 processors, the PAUSE instruction operates like a NOP instruction. The Pentium 4 and Intel Xeon processors implement the PAUSE instruction as a pre-defined delay. The delay is finite and can be zero for some processors. This instruction does not change the architectural state of the processor (that is, it performs essentially a delaying no-op operation).

define struct union

racket 6.0 вышел:

* новый пакетный манагер
* базавая установка распилена на > 200 пакетов
* компилятор JIT для arm
* значительный улучшения производительности в typed/racket
* Новый профайлер для контрактов сообщает как долго проверяются контракты.
(дохера важная фича кстати)

http://blog.racket-lang.org/2014/02/racket-v60.html

Палю ультрагодноту по интерпретаторам
The Structure and Performance of Efficient Interpreters
http://www.jilp.org/vol5/v5paper12.pdf

Надо себе на ебальнике выбить уже.
Type ILP64 LP64 LLP64
char 8 8 8
short 16 16 16
int 64 32 32
long 64 64 32
long long 64 64 64
pointer 64 64 64

Чят, как ты можешь изучать всякие плюсошаблоны и прочие изъебства, зная что есть
гораздо более красивые, выразительные и мощные средства абстрагирования через
метапрограммирование?

history of programming languages
http://thequickword.wordpress.com/2014/02/16/james-irys-history-of-programming-languages-illustrated-with-pictures-and-large-fonts/

Пытаться чото делать в embedded после того, как 4 года его не трогал, это жесть какая-то.

Чото у каждого второго айтишника в резюме вижу что он знает C.
Еще хуже если там написано "C/C++".

Теперь внимание вопрос: На каком уровне надо знать (какой опыт иметь в) C, чтобы
иметь моральное право указыать ее в резюме, и, при этом, не быть голословным
мудаком?

Смотрите, что я нашел.
Real lambda support for bash (a functionally complete hack). Includes a set of
functions for functional programming,
list allocation and traversal,
futures,
complete closure serialization,
remote closure execution,
multimethods,
and
(вдохнули? готовы?)
concurrent mark/sweep garbage collection with weak reference support.
https://github.com/spencertipping/bash-lambda

Иногда когда мне совсем нехер делать я хожу по разным старым проектам и пытаюсь их запустить.
На этот раз наткнулся на Unigine 0.2, последнюю опенсорсную версию. (Unigine потом стал закрытым и успешным).
OpenGL там конечно старый (1.4) и с кучей расширений, однако сама демка интересная, в т.ч увидел там:

• soft shadows
• портальный рендеринг с исползьванием bsp-trees
• система частиц
• зеркала
• автоматические тени от всех объектов
• простая rigid-body физика (даже с joint-ами)
• объемный туман
• просто скриптовый язык с консолькой по ~

Допинал исходники чтобы компилялись на современных линупсах.
https://github.com/4DA/Unigine-legacy

yay, только щас узнал про OpenGL Bindless extensions.
Вкратце - снимается оверхед на последовательный биндинг наборов buffer objects
(и улучшается cache locality)

http://developer.download.nvidia.com/opengl/tutorials/bindless_graphics.pdf

куркума спалил: http://natashenka.ca/posters/

Узнал сегодня про макрос with-method, который я оказыется успешно перезобрел пару раз.

Макрос извлекает методы ил класса и биндит их как функции на область действия.

(with-method ((id (obj-expr method-id)) ...)
body ...+)

http://docs.racket-lang.org/reference/ivaraccess.html?q=with-#%28form._%28%28lib._racket%2Fprivate%2Fclass-internal..rkt%29._with-method%29%29

@like-all -> @0xd34df00d
Божечки, какие мы нетерпеливые. Настолько, что забыли про термин AFK. Во-первых, ты не следователь, а я не подсудимый, так что я обязан тебе ровно ничем. Если это как-то нарушает восприятие мира тобой - извини. Во-вторых, раз пошла такая пьянка, я распишу про овердизайн. Один раз. Здесь.

Представим среднего девелопера, который хочет запилить графическое десктопное приложение. Чем ему могут быть полезны личкрафты? Отлично, имеется богатое API, с помощью которого можно передавать мессаджи, объекты и прочие сущности из плагина в плагин, назначать табклассы, получить доступ к унифицированному тулбару, сайдбару, засунуть небо в аллаха и аллаха в небо. Возможно, это прекрасно, но... "НО ЗАЧЕМ?", резонно спросит средний девелопер и уйдёт пользоваться Qt, DBUS, xdg и прочими благами, которые ему даны фридесктопом. Да, конечно, API поверх API поверх API - это сейчас модно, но девелопер вряд ли захочет прибивать гвоздями своё приложение к малоизвестному рантайму для плагинов, да ещё и получать геморрой в виде деспотичного цензора в лице дедфуда в количестве одна штука. Что в этом случае делать? Форкать? Да кому нахуй нужно мейнтейнить всё это безобразие для того, чтобы поддерживать одно простое графическое приложение, да ещё и следить за тем, чтобы API не было outdated? Куда проще взять готовый фреймворк, использовать свой кодстайл, инструменты для сборки, языки программирования и другие общепринятые блага цивилизации.

Возьмём среднего обывателя, пользующегося бытовым электрическим компьютером. Основной lifecycle приложения под управлением пользователя, как мы знаем, это открыть приложение -> выполнять в нём действия до достижения удовлетворения -> закрыть приложение. Среднему пользователю, обычно, поебать на то, как устроено приложение, лишь бы выполняло свои действия в удовлетворяющие пользователя временные рамки и к нему не нужно было долго привыкать. Мир, конечно, знает немало коммерчески успешных комбайнов, взять хотя бы те же iTunes и Opera. Но у них есть одна отличительная черта: они после запуска предоставляют пользователю простые и понятные средства для доступа к основной своей функциональности. Всё остальное скрыто от глаз подальше и появляется только в том случае, если пользователь того захочет. То есть, iTunes даёт пользователю плейлист, табло и контролы для управления музыкой - основной функциональности данного приложения. Если пользователь подключил iPhone, то можно и предложить сбэкапить данные, закинуть музыку, обновить прошивку, ещё чего-нибудь. Opera сразу предоставляет пользователю вьюпорт браузера, табы, навигационную панель и статусбар. Всё, ничего лишнего. Если пользователь захочет, он может тыкнуть в mailto: или irc://, а дальше сам разберётся, открывать ему это внутри приложения или же воспользоваться своими любимыми клиентами. Резюмируя: эти приложения не кричат всем своим естеством "СМОТРИТЕ, Я МОГУ ЗАМЕНИТЬ НЕБО И ОЛЛАХА", а сразу дают пользователю то, чего он от него ожидает получить. И только потом всё остальное. А потом пользователь их закрывает. И ожидает, что они запустятся относительно быстро. Что же мы видим в личкрафтах? Очень долгая инициализация в случае подгрузки всех необходимых плагинов, буйное разнообразие табов, сайдбаров и тулбаров. Немудрено, что пользователь испугается, если он, конечно, не ебанутый. В прыщах это ещё как-то может прокатить, если сабжем заменить десктопное окружение. Вопрос в том, найдётся ли тот аутист, который согласится поставить себе в качестве десктопного окружения помесь чебурашки с франкенштейном. Когда я в последний раз на них смотрел, то видел, что сайдбар в скором будущем может заменить вкладки. Подход здравый, щас многие так делают. Но тут уже непонятно, что будет в качестве wm и как это всё будет уживаться с доком внутри вьюпорта графическогот приложения. Разве что док в отдельное окно перемещать и снэпить его к какой-нибудь из сторон экрана. Но это всё прыщи. А что с самыми популярными быдлоориентированными ОС ака Windows и Mac OS X? Всё по-прежнему будет в одном окне. И сайдбар будет дублировать функциональность дока в макоси и супербара в винде. Не совсем очевидно, как юзать табклассами и разносить всё безобразие в отдельные окна, настраивать связи файлов с этими плагинами, организовывать правильный автозапуск и распихивание на воркспейсы. Проще открыть в приложении, воспользоваться и закрыть. А все необходимые API и интерфейсы и так предоставят операционные системы. Единственной перспективной частью в личкрафте является Azoth. С современной фрагментацией IM эта штука могла бы быть очень полезной, поскольку умеет в разные протоколы и предоставляет универсальное API. LMP очень плохо работает на альтернативных ОС, ибо Phonon - говно. Я, конечно, слышал про переход на Gstreamer, но не знаю, как с ним сейчас обстоит дело. Да и, наверное, знать не хочу.

Вот. Я всё сказал. А теперь ты отправляешься в BL.

Начал писать гуевую програмулину (спалю потом чоза, если взлетит).
Так вот оказалось что это дохера не просто и ебко в плане организации работы и архитектуры всего этого говна.

вывод: нехер обсирать личкрафты пока сами такое не сделаете (срсли (не тралю))

Чят, а у тебя бывает такое, что ты устал и вместо выполняния основных запланированых задач или проектов (для выполнения которых необходимы определенные ментальные усилия) делаешь всякий кодинг тривильных програмок/скриптов или чтение всякого фастфуда (но, тем не менее с ненулевым выхлопом).
Считаю это отличной альтернативой двачеванию интернетов и доказывания мудакам, что они мудаки, например.

Теперь заживем:

/Yalo is a Lisp OS running on bare metal x86-64 hardware. The system programming language is Ink, a new Lisp dialect which combines the elegance of Scheme and powerfulness of Common Lisp/

https://github.com/whily/yalo