Наигрался с AVR, хочу изучить ARM-микроконтроллеры. Заказал минималистичную плату с STM32F103C8, теперь выбираю программатор. С одной стороны было бы не плохо, если бы он был универсальным (то есть поддерживать не только STM), с другой без проблем завестись под онтопиком.

Присмотрелся к такому: http://www.aliexpress.com/item/ARM-Emualtor-supports-ARM7-ARM-ARM9-ARM11-Cort....

В списке поддерживаемых ОС в описании товара Linux нет, однако на официальном сайте JLink есть deb-пакет, однако для загрузки требуется указать серийный номер программатора.

Ну а теперь вопрос: получится ли так сделать? Вопрос к знающим людям:

1) Насколько легко заводится JLink под Linux

2) Является ли вышеуказанный JLink официальным и имеющим серийный номер или же это клон. Если клон, то подойдёт ли серийный номер (на фотографии товара фрагмент коруса замазан, возможно, там серийный номер) для загрузки драйвера с оф. сайта

3) Если на оба вопроса ответы отрицательные, то что тогда можете посоветовать для прошивки ARM под онтопиком (не дорогое)?

4) И вообще, нет ли полностью универсальных USB-JTAG адаптеров? Вроде, что у AVR, что у ARM, что у FPGA линии JTAG одинаковые (земля, 4 линии данных, опционально питание). Различаются только команды, которые по этому интерфейсу передаются. Что мешает базу микроконтроллеров и ПЛИС вынести в софт программирования на ПК, а адаптер сделать тупой передавалкой указанных байтиков по JTAG? С одной стороны это должно удешивить программатор (программа для микроконтроллера программатора элементарная, мощность тоже большая не требуется), позволит купить его только один раз, а не для каждого семейства чипов, с другой поддержка новых чипов будет добавляться обновлением софта на ПК, а не покупкой нового программатора или обновлением его прошивки.

UPD: Прочитал, что OpenOCD поддерживает JLink и не только. А ещё, что можно в качестве адаптера использовать FT232 и шить всё подряд (ПЛИС, AVR, ARM). Но всё равно хотелось бы услышать мнение знающих людей.

Учитывая весь шум, который поднимается вокруг лисповских макросов, вокруг их необычайной мощности и выразительности, я был несколько удивлен довольно уничижительным высказыванием в их адрес, подкрепленным примером:

Yes, there is a macro mechanism in PicoLisp, to build and immediately execute a list of expressions. But it is seldom used. Macros are a kludge. Most things where you need macros in other Lisps are directly expressible as functions in PicoLisp, which (as opposed to macros) can be applied, passed around, and debugged. For example, Common Lisp's DO* macro, written as a function:

(de do* "Args"
   (bind (mapcar car (car "Args"))
      (for "A" (car "Args")
         (set (car "A") (eval (cadr "A"))) )
      (until (eval (caadr "Args"))
         (run (cddr "Args"))
         (for "A" (car "Args")
            (and (cddr "A") (set (car "A") (run @))) ) )
      (run (cdadr "Args")) ) )

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

Так может быть легенды о мощности лисповских макросов сильно преувеличены? Может быть, их использование — это, всего лишь, дань моде и вынужденный компромисс между выразительностью языка и возможностью компиляции?

Здравствуйте! Я хочу написать игру с физикой. Что будет в этой игре я пока точно не знаю(по ходу разберусь), но знаю что там будет очень много разрушений построек, объектов и блэкджек . В качестве графического движка буду использовать Ogre, но не знаю какой физический движок выбрать. Я хотел бы использовать bullet, но не знаю как там обстоят дела с разрушениями и вообще, как он смотрится по сравнению с physx && havok. Да я знаю про лицензии и, что physx под nvidia и прошу это не учитывать.

Меня интересует только функциональность и производительность.

По метаобъектным системам информацию днём с огнём не сыщешь (что доказывает их нужность :trollface:). Книг тоже меньше, чем три с половиной (или их тоже хрен найдёшь). Да и вообще, складывается такое впечатление, что за пределами Common Lisp к метауровню объектных систем относятся исключительно как «Ух ты, класс класса» — как к забавной, но не глобально продуманной идее. Ими можно пользоваться, чтобы добавить метод-другой, но они не позволяют действительно влиять на объектную систему. Разве что в Руби через призму Гугла и Stack Overflow видится некоторое шевеление на эту тему, но у них там какой-то свой особенный хипстерский мирок, в который я пока не вник.

Так это, я нахожу несколько странным вывод следующей программы:

(defclass extended-class (standard-class)
  (additional-slot) )
 
(defclass extended-object ()
  ()
  (:metaclass extended-class) )

(defun print-metaclass-slot-names (class-name)
  (let* ((metaclass (class-of (find-class class-name)))
         (metaclass-slots (class-slots metaclass))
         (slot-names (mapcar #'slot-definition-name metaclass-slots)) )
    (format t "~a: ~a~%" class-name slot-names) ) )
 
(print-metaclass-slot-names 'standard-class)
(print-metaclass-slot-names 'standard-object)
(print-metaclass-slot-names 'extended-class)
(print-metaclass-slot-names 'extended-object)

Например, я хочу создать иерархию наследования, независимую от существующей. Пусть в ней все классы будут обладать дополнительным слотом abstract, который говорит, применима ли к ним make-instance. То есть я такой создаю свой abstractable-class с этим слотом, его экземпляр называю abstractable-object — это альтернативный корень иерархии наследования, у которого abstract = nil. Но сам метаобъект класса abstractable-class не имеет этого слота, чем нарушает мою хотелку «все классы (новой иерархии) имеют слот abstract».

Удобно таскать с каждым темплейтоклассом типы с которыми он специализируется. Но с variadic template-ми что-то не выходит. ЧЯДНТ?

#include <iostream>
#include <functional>

using namespace std;

template <typename... Args>
class Func;

template <typename T, typename... Args>
class Func<T(Args...)> {
public:
	using RetT = T;
	using FunctionT = function<T(Args...)>;
	
	using ArgsT = Args; // <-- error
};

template <typename T>
class FuncBox {
public:
	typename T::FunctionT func;
	
	typename T::RetT call(typename T::ArgsT... args) {
		return func(args...);
	}
};

int main() {
	FuncBox<Func<int(float)>> w;
	
	w.func = [] (float x) -> int {
		cout << x << endl;
		return 4;
	};
	
	w.call(7);
	
	return 0;
}

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

cast Zubok

P.S. Вдруг кто знает. А реально ли будет поступить на Аспирантуру за границей при наличии Российского высшего образования (бакалавриат) по такой специальности?

Раз уж пацаны гонят оголтелый треш в последнее время в галерее, то тут такое дело:

Не сколько скриншот рабочего стола, хоть не без этого, сколько скриншот демонстрирующий удобную настройку редактора с одним конфигом - для разных задач, с разными цветсхемами для различных терминалов. Всё работает без изменения конфига (~/.vimrc).

Этот пост-скриншот для тех, в большей степени новичков, кто не в курсе дела такой возможности настройки.

Я вообще постоянно использую 4 терминала + tmux в некоторых из них, это: urxvt, практически идеальный Terminal-0.4.8 (сейчас называется xfce4-terminal-0.6.x - но оно неюзабельное и с багами), гибко настраиваемый ROXterm и относительно новый и малоизвестный пользователям-рабам тяжелых DE - крутой и моднейший клавиатуро-ориентированный(sic!) терминал termite (вимерам юзать однозначно!).

Каждый терминал для определенной (не жестко) задачи или настроения: для руби, md/haml/coffee, для Си или Эрланга. Для манов через vimpager. Для системных конфигов. Разные цветсхемы, различные шрифты - со сглаживанием или без. С различными схемами не только вима, но и статусбара/интерфейса вима, причем в одном случае это vim-powerline, в других vim-airline в свою очередь также с разными цветами. Кайфотне.

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

if $COLORTERM == 'Terminal'
    желаемые настройки
endif

Также можно можно настроить вим менять схему и интерфейс в зависимости от дня недели и времени суток, например днём светлую, ночью тёмную:

let weekday=system('date +%u')
let hour=system('date +%H')
if hour == x
  бла бла
endif

Не каждый терминал возвращает $COLORTERM, например Terminal и urxvt - да, а все остальные из списка нет. Поэтому я запускаю их как скрипты на хоткее следующего содержания, например termite.sh:

#!/bin/bash
export COLORTERM="termite" && /usr/bin/termite --geometry=1248x620+60+40

Ну и детали:

Gentoo GNU/Linux 3.10.5-geek
Awesome-3.4.15
тема осома: Penumbra

На скриншоте Vim 7.4 (не gvim), некоторые цветсхемы работают благодаря плугину CSApprox.

Только полный кастом или никак, пацаны!

Такие дела.

Привет.
Есть редактор вида: слева история версий файла, справа сам файл? (http://rghost.ru/53864895/image.png).
Именно история файла, а не дерево репозитория, которое нужно перезагружать, чтобы добраться до файла.

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

предполагаемая задача:

создать утилиту degrep которая делает вывод следующего за ней grep в тем-же аргументом пустым. 

• критерии успеха: `cat $file | degrep $pattern | grep $pattern` всегда пуст вне зависимости от pattern и для любых файлов. pattern соответсвует POSIX и не эквивалентна .*
• критерий сравнения: разница(например xdelta) между `cat $file` и `cat $file | degrep $pattern` минимальна.
• критерий серьёзной заявки - софтинка должна давать лучший результат чем grep -v pattern и sed s/pattern// (то есть лучше тупой инверсии условия/удаление подстрок)
• критерий победы близкой к абсолюту: утилита `undegrep $pattern` восстанавливающая исходный текст файла после degrep. То есть изменения внесённые degrep каким-то образом обратимы.
• требований по скорости не предъявляется - программа должна завершаться за разумное время. Скажем не больше 20 мин на текст не более 10К
• абсолютный абсолют - degrep и undegrep одна и та-же программа. В теории это возможно.

PS. у меня готовых решений нет :( буду на общих условиях

PPS. приветствуются даже подходы к её решению, без приложения кодов :) очень лихая вводная получилась

Я тут один «типа НИОКР» пилю с коллегой. Общался с разными людьми - уже 4 раза слушал совет (данный совершенно серьезно) «ты диссертацию на этом напиши! работа то реальная, профиты поимеешь».

А у меня даже в\о нет.

Вопрос:
Может ли человек без в\о и вообще не имеющий образования по теме написать некую работу, которая будет иметь некий, скажем так, «признаваемый статус»?

Задумался еще после того, как почитал по моей теме («виртуальные музеи») доклады и научные работы некоторых «признанных научных сотрудников». П-ц. Там такое... уровень школьного доклада. Зато с кучей типа терминов, списком литературы, цитатами, схемами и соавторами. Волосы дыбом.

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

Народ, посоветуйте чего ботать для вникания в теорию множеств?

Всем привет, возник следующий вопрос. Можно ли как-то ускорить вывод графики через glBegin/glEnd или это совсем гиблый способ? Имеется довольно много объектов, которые следует вывести, и данный метод заметно тормозит, причем тормоза сильно отражаются и на процессоре. Насколько я знаю, при вызове данных функций данные передаются из оперативной памяти в видеопамять по довольно медленному соединению. Также, знаю, что лучше использовать VBO для ускорения вывода графики.

С VBO тоже проблемы. Знаю о нескольких типах буферов, из которых меня в данном контексте волнуют только буферы вершин, цветов и текстурных координат. Возникает законный вопрос, как среди тысяч прямоугольников, передаваемых в массиве, каждому из них назначить свою текстуру? Как повернуть каждый из них (замена glRotateF), как масштабировать (замена glScaleF), как задавать стиль наложения (glBlendFunc)?

Если предположить, что все вышеперечисленные вопросы решены, то возникает еще один - по организации простого движка, поддерживающего VBO. Допустим, у нас есть множество прямоугольников с текстурами, параметры которых меняются на каждом кадре. Те же боевые единицы в какой-нибудь игре. Есть ли смысл на каждом кадре полностью пересоздавать все буферы или надо менять все эти значения прямо в памяти? Мне подобный метод видится со следующей реализацией:

1. Вызываем метод Draw движка для очередного прямоугольника. Передаем в него все необходимые параметры: Номер текстуры, Координаты (допустим, центра), Размеры, Угол поворота, Цвет, Прозрачность.

2. Движок добавляет координаты и иные параметры переданного прямоугольника в массив, сортирует их по нескольким массивам. На этом этапе, опять же, встают вопросы про использование таких параметров, как, например, угол поворота.

3. При вызове функции Redraw движка созданные массивы посылаются в память в качестве буферов и рисуются.

4. Также, при вызове некоторых других функций производится принудительная передача массивов в память, их рисование и очистка. К таким функциям относится, например, смена масштаба сцены (glScaleF), если предположить, что объекты, рисуемые с одним масштабом, передаются группами, друг за другом. Также, к таким функциям можно отнести glBlendFunc - для смены стиля наложения текстуры.

В общем, интересуют все идеи по данной теме. Заранее спасибо.

В первую очередь интересуют языки и скорость работы. Я нашел, что можно писать на vimscript, python, scheme и lua. А также, что python раз в 20 быстрее vimscript, а luajit чуть ли не в 1000 (правда там не говорилось, в какой момент этот lua компилируется, но я почти уверен, что на старте vim'a). Про схему пока не искал, да и не очень хочется экспериментировать с малознакомым языком.

Во-вторых, интересуют подводные камни разработки плагинов под vim. Как я понимаю, функции должны быть очень быстрыми, чтобы интерфейс не подвисал. Поэтому я хочу вынести всю тяжелую работу в отдельный процесс, который взаимодействует с плагином через, например, shm. В плагине, соответственно, будет только чтение данных. Нет данных - нет автодополения, подсветки etc.

Теперь о самой задаче. Мне нужен редактор кода, который умеет работать с cmake-проектом. Из того, что я использовал, ближе всего к моему идеалу KDevelop, но уже давно хочется большего. Что-то близкое по функционалу, обычно имеет схожие проблемы, но не имеет шикарной подсветки и не менее шикарного частичного автодополнения по tab'у (+ многое еще и на Java).

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

Сейчас еще попытаюсь заставить qtcreator работать с существующим cmake-проектом. А пока поделитесь опытом написания плагинов к vim на lua и/или python.

Тут запредельное количество гитаристов и гитарастов...

Посоветуйте хорошие книги/видео/учебники/маны по теории музыки?

(Пример «хорошей практики»: «Попов. Музыкальное и аппликатурное мышление гитариста».)

Какие разделы знания вы считаете наиболее важными?

Нужно для: анализ структуры существующей музыки, создание(/импровизация) по готовым структурам, адаптация под классическую/электронную гитару

Особенно интересны отзывы практиков в джаз/блюз/рага/итп (нестандарт)

(линукс тут не при чем - к удалению. пусть повисит пару часов утром?)

Есть ли простой путь замены CL-овского #. ?

Например, кусок кода

(case ftype
                   ((#.(keyword->g-type :enum)
                       #.(keyword->g-type :flags))
                    (convert-to-foreign value (g-type->lisp type)))
                   (#.(keyword->g-type :double)
                      (coerce value 'double-float))
                   (#.(keyword->g-type :float)
                      (coerce value 'single-float))
                   ((#.(keyword->g-type :int)
                       #.(keyword->g-type :uint)
                       #.(keyword->g-type :long)
                       #.(keyword->g-type :ulong)
                       #.(keyword->g-type :int64)
                       #.(keyword->g-type :uint64)) (round value))
                   (t value))

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

Могу вручную выполнить (keyword->g-type :uint), (keyword->g-type :long) и подставить в код результаты. Но будет пачка «магических чисел» в коде. Причём, если в следующей версии будут другие числа у ключевых слов, придётся как-то искать все места использования.

Что посоветуете?

Интересует вопрос, можно ли в диалектах Lisp писать макросы, которые преобразуют не один S-expression, находя его по первому элементу списка, а позволяют указать более сложный шаблон, по которому искать дерево для трансформации?

Чтобы было понятнее, пример на псевдоязыке:

(defmacro (swap-begin _* :as contents swap-end)
  (reverse contents))

Такой макрос по задумке должен выдать все S-exp между swap-begin и swap-end в обратном порядке:

=> (macroexpand '(swap-begin (+ 1 2) (println "whatever") (/ 2 1) swap-end))
((/ 2 1) (println "whatever") (+ 1 2))

Извиняюсь, если получилось немного сумбурно; надеюсь, общая идея понятна.

У самого есть подозрение, что нужно глубже гуглить по словам reader macro или code walking, но не уверен (я пока только начинаю знакомиться с Lisp).

Под эквивалентностью я подразумеваю равенство выходных данных и произведенных побочных эффектов

Например, для двух функций вычислений n-го числа фибоначчи (питон)

def fib1(n):
    a, b = 0, 1
    for _ in range(n):
        a, b = b, a + b
    return a

def fib2(n):
    if n < 2:
        return n
    return fib2(n-1) + fib2(n-2)

Питон тут для примера, для какого-нибудь лиспа, наверное, проще будет сделать это

Язык английский или русский, с хорошей системой поиска.

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

08-09 - одеться, помыться, позавтракать
09-10 - приехать на место работы
10-19 - поработать на месте работы
19-20 - доехать до дома
20-21 - погулять с собакой
21-22 - свободное время
22-08 - спать, если сплю меньше, не высыпаюсь

Проблема даже не в том, могу я украсть у сна 2-4 часа или нет. А в том, что если начну «красть», буду чувствовать себя как говно всю неделю.

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

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

UPD: Так горело, что создал тред. Не сплю в 4 утра, т.к. задолбало конкретно и взял неоплачиваемый отгул и купил бухла. Так горит, что хочется уволиться, наплевав на все обязанности, задолженности и прочую денежную хрень.

Вразумите глупого.

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