SoUrcerer wrote:Нет-нет, версия 0.7.7.0 нормально открывает. А вот в 2203й сборке downloader скачивает A000 байт, и завершается.
Вместо google.com скачивается страница с ошибкой 301.
Вместо google.com да скачивается страница с ошибкой, но вот google.ru скачивается нормально, mail.ru тоже нормально, а вот с yandex.ru и ya.ru также есть проблема.
SoUrcerer wrote:По непонятным причинам у меня нормально открывается Яндекс в 0.7.7.0, и я вижу сообщения сервера вместо содержимого веб-страницы в .download в ночной сборке.
Я в целях эксперимента вернул в последнее ядро socket.inc и tcp.inc из ревизии 2123, пришлось еще и процедуру wait_mutex восстановить. В результате сеть заработала как раньше. Делаю вывод, что дело не только в порче регистров, которые уже исправлены. Я проверил все обращения к новому коду мьютекса в socket.inc и tcp.inc, потерь содержимого регистров при вызове - нет. Остается предположить что частично нарушена логика работы мьютекса именно в сетевой части. Новый мьютекс имеет более хитрую структуру и пока я его не раскурил окончательно.
Разъясните, пожалуйста, мне (и другим я думаю тоже будет интересно) простым языком какие изменения были произведены в последнее время с ядром (acpi, мьютексы и т.д.) и что они конкретно дали Колибри.
Хех... это уже не ко мне вопрос. Тут двое ведущих специалистов наворотили.
Часть изменений можно прочитать в Динамическое определение дисковых устройств
А Serge что делает описывается вообще редко - только по логу SVN и можно пытаться что-то понять.
Ёжики кололись и плакали, но продолжали жрать (драть?) кактусы.
SVN r. 2208 еще одно исправление для r.2129. Я очень надеюсь что последнее, хотя бы для сетевой части ядра. Давно я так не уставал.
Да, и не спрашивайте меня почему HTMLv не работает - я за него не отвечаю.
Вот та его версия которая была пару версий назад - работает, но иногда лагают ссылки, хотя те же ссылки вбитые вручную прекрасно открываются.
Старые мьютексы тупо жрали процессорное время в цикле с change_task. Новый код блокирует поток до тех пор, пока мьютекс не будет освобождён. Планировщик не делает лишних переключений контекста, загруженные потоки раньше получают управление или процессор дольше спит на hlt, мобильные компьютеры меньше потребляют -- PROFIT.
Leency wrote:Очень давно наблюдал этот баг с белой рамкой. А ещё здесь налицо странное поведение окон. Наверное, именно из-за этого и есть правильное поведение окна KFM при прокрутке и странное поведение Эолайта см. вложение download/file.php?id=2865
Баг с рамкой исправил в ревизии 2214 - он появился в ревизии 1474.
Этот баг никак не связан с багом Eolite, потому что баг Eolite есть в ревизии 1466, которая была до 1474.
Я подозреваю, что проблема в том, как ты определяешь - является ли приложение самым верхним в стеке окон. Ползунок начинает рисоваться до того как окно стало активным.