Board.KolibriOS.org

Не понимаю, почему в моём коммите отправился ещё и board.asm, я же его не редактировал. Если что-то с ним случилось не то, поправьте...
Но зато я исправил досадные недочёты в русской локализации stackcfg, добавил украинскую, и перевёл AIRC.

_________________
Всех выше те, кто доброе творят,
И за дела добра не ждут наград,
Всем жертвуют для страждущих людей,
Не думая о выгоде своей.

Атауальпа
Я исправил твою оплошность, но на будущее будь внимателен - мне или кому-то еще не доставляет быть дворником и прибирать за кем-либо.

Спасибо! Я использую консольную версию subversion, и пока владею этим не очень уверенно, поэтому использовал для коммита команду, которая просто отправляет всё новое, что появилось в рабочей копии. А как там оказалась другая версия board.asm — сам не понимаю, но постараюсь разобраться...

_________________
Всех выше те, кто доброе творят,
И за дела добра не ждут наград,
Всем жертвуют для страждущих людей,
Не думая о выгоде своей.

Атауальпа, нельзя так делать. Во-первых, в попавшей на svn в ревизии 1723 версии AIRC исчезла поддержка английского языка, которую убирать явно недопустимо: можно ожидать, что русскоязычный пользователь поймёт английский текст - тем более, что его там немного, - но нельзя заставлять остальных пользователей - не только англоязычных - будет разбираться в русском. Во-вторых, совершенно незачем портить много лишних строк кода - svn может показать информацию о том, какая строчка в какой ревизии появилась, и сбивать этот механизм с толку совершенно ни к чему. В-третьих, предложение по умолчанию данных конкретного пользователя вместо обобщённого "kolibri_user" выглядит исключительно странно. Я вернула файл airc.asm в тот вид, в котором он был до ревизии 1723, при желании довести это до ума неправильную версию можно извлечь стандартными средствами svn. Я также вернула файл board.asm: правка Mario79 почему-то свелась к то ли убиранию, то ли добавлению пустой строчки, что никак не влияет на некомпилябельность из-за неверного пути к macros.inc.
Я обращаю внимание, что при использовании консольного клиента Subversion можно - и нужно - посмотреть, какие изменения будет заливать svn по команде commit с помощью svn diff.

_________________
Сделаем мир лучше!

Я вообще-то откатил к 1722 (или думал что откатил), и добавил пустую строку так как с e-SVN фрон-енд ничего больше не мог предложить. Компиляемость действительно не проверял. Видимо я промахнулся цифрой. Извиняюсь за предоставленные неудобства - спешить надо только в трех случаях и это очевидно не тот случай.

В новой ночной сборке плохо работают клавиши Enter и пробел: выводят ASCII-коды 28 и '9' соответственно. Это проблема не в данных - данные взяты из последней ночной сборки от diamond'а - и не в сборке как таковой - из-под Колибри файлы с данными читаются нормально - и, как пишет Mario, даже не в ядре и не в драйверах - замена ядра и драйверов на новые в последней ночной сборке от diamond'а не нарушает работы.

Yes, I remember this happened a while ago to the main distro, but I'm sorry to say that I forgot what the problem was

EDIT: Is it not just the scan-codes that are fucked up ?

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

No. The scan-codes of keyboard are correct.
I guess there is something wrong with @panel, or load keymap, or any another reason. I'll look for it.

Еще интересный баг: запускаю программу, убиваю ее по Alt+F4, нажимаю Alt+F4 вновь - и запускается убитая программа... Это дело рук panel, верно?

При описании багов чем подробнее, тем естественно лучше - какая программа? В какой версии ядра? Делались изменения самостоятельно или чистая сборка (если ночная, то от какого числа)?

Сборка из builds.kolibrios.org, если память не изменяет, 1741. Проявляется баг со всеми программами и на реальной машине, и в qemu. В последней ночной сборке от diamond еще работало.

Прорблему с генерацией неверного ASCII для клавиш Space и Enter я решил, пофикшенный @ss.asm залит на SVN, но скрипт сборки образа поломался вроде - на каждый коммит генерирует ошибку.

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

Та же сборка, в памяти только OS/IDLE и @panel. Нажимаю на кнопку Menu, затем жму Alt+F4, открывается первый пункт меню. Снова Alt+F4 - подменю, третий раз Alt+F4 - запускается C4, четвертый раз Alt+F4 - закрывается C4, пятый раз Alt+F4 - открывается Menu, и так до бесконечности.

UPD:C 1629м ядром такая же картина. Но Alt+F4 убитые процессы не восстанавливал еще

Дело в ICON.Кажется. А может и нет.
При закрытии по Alt+F4 фокус кажется переходит на ICON, и повторный alt+f4 запускает программу снова (как происходит с panel и menu). Если запускать программу из меню, то повторный Alt+F4 открывает меню, если из CPU - то убивает программу CPU. Это как-то связано со статусом @-приложений, похоже.

При старом ядре и старых программах бага нет, при новом ядре и старых программах тоже бага нет, при новом ядре и старых panel, ss, rb, clip бага тоже нет. Остается icon.

Старое ядро, старые программы (1629), новый ICON - баг присутствует.
Новое ядро, новые программы (1741), старый ICON - бага нет.
Просматриваю SVN, вроде бы изменений в ICON внесено не было...

С 872й редакции ICON не менялся. А размер скомпилированной версии изменился на 2 байта. Дело либо в include-ах, либо в версии компилятора.
UPD: между 1600ми и 1740ми ревизиями связанные с ICON макросы не менялись, менялся только build_all.bat.