Windows 8

 
1 7 8 9 10 11 12 13

Bod

координатор
★★★

Bod>> А разве 8-ке нужен антивирус? Туда же вроде бы MSE встроили?
Mishka> А он от этого перестаёт быть антивирусом? :F

Ты не так понял. Я к тому, что восьмёрка вроде как не нуждается в установке дополнительного антивируса. Раз есть штатный.
 24.024.0
+
-
edit
 

Balancer

администратор
★★★★☆

Nikita> Ну причём здесь 3D :facepalm:

s/3D/GPU/

Что-то поменяется? :)

Nikita> Откройте в отладчике minidump

Было б ещё понятно, в чём его открывать. MS и тут в своём репертуаре, неужели сложно в human readable что-то скинуть?

Nikita> Последнее время, помимо видеодрайверов, массово глючат драйвера для радиожелезяк. Bluetooth, WiFi и т.д.

Один фиг, если не шашечки нужны, а чтобы ехало.
 30.0.1599.10130.0.1599.101
+
+1
-
edit
 

Balancer

администратор
★★★★☆

TEvg-2>> Да вообще непонятно что можно считать на GPU при поиске и при разборе HTML.
Mishka> А ты попробуй напиши парсер.

15 лет назад HTML был такой же, как сейчас (то, что тегов стало больше не усложняет грамматику), а парсился без тормозов на первопнях, а сносно — на 80486 :) Без всяких GPU.

Ну и вопрос изначально был, всё же, вообще про работу с полем ввода в GUI.
 30.0.1599.10130.0.1599.101
+
-
edit
 

Kuznets

Клерк-старожил

Mishka>> А ты попробуй напиши парсер.
Balancer> 15 лет назад HTML был такой же, как сейчас (

Даже я сильно сомневаюсь в этом. В современной мешанине выдаваемой за html еще поди найди то что нужно.

Balancer> Ну и вопрос изначально был, всё же, вообще про работу с полем ввода в GUI.

Ты же писал что "в браузере"
 
+
-1
-
edit
 

Mishka

модератор
★★☆
Balancer> 15 лет назад HTML был такой же, как сейчас (то, что тегов стало больше не усложняет грамматику), а парсился без тормозов на первопнях, а сносно — на 80486 :) Без всяких GPU.

Полный HTML и тогда не парсился быстро. И тесты не совместимость не зря появились. :F Что выручало — размеры HTML страничек были маленькие. И не всё использовалось. А уж, как пошли динамические страницы с использованием таблиц и тысяч и десятков тысяч элементов, так всё и присело. При этом проблемы поведения браузеров до сих пор есть. Строго говоря, страничку нельзя показвать, пока последний тэг не проверен, но народу ждать не охота. Поэтому и делают показ "на лету". А в результате странички часто дёргаются.

Balancer> Ну и вопрос изначально был, всё же, вообще про работу с полем ввода в GUI.
Дык, там важно, что завязано на семантику этого поля. Если делать, как когда-то в Fox-е том же, когда на каждый чих выполнялся запрос по базе, чтобы всё сразу показать, то на маленьких базах всё летало. Как только базы стали содержать десятки тысяч записей, то летать перестало. А к сотням тысяч всё поползло. Вот придумали MS (я на самом деле не знаю, просто из головы) находить файлы, которые могут подходить под вводимые буквы в режиме вставки звёздочки после каждой буквы. И шарить это по индексам. Можешь оценить, сколько там будет работы, причём часто линейного сканирования того индекса файлов. Вот и решили ускорить сканирование — типа маски построили и загрузили в GPU, а потом кормим поток строк, а в параллель выполняем операцию сравнения, где подошло, там и показываем. Я не говорю, что это лучшее решение, но вполне могу себе представить, как люди его делают. :F
 24.024.0
+
-1
-
edit
 

Balancer

администратор
★★★★☆

Kuznets> Даже я сильно сомневаюсь в этом. В современной мешанине выдаваемой за html еще поди найди то что нужно.

Общая логика осталась той же самой. Наоборот, давно пытаются упростить его в плане парсинга и все новые версии куда более простые и строгие (всё, что XHTML/HTML5). Так что самый сложный HTML, как раз, старый. И за последние годы усложнений в плане грамматики языка там не было. Только семантика частично росла, частично, наоборот, урезалась.

Другое дело всякие JavaScript и реализация функционала HTML5, CSS3 — он стал намного сложнее. Но это задача не парсинга, о которой речь шла. И вот в обработке CSS3, например, GPU как раз вполне себе на месте. Там много сложных матричных операций.

Kuznets> Ты же писал что "в браузере"

В браузере, но на не браузерной задаче. Обычный поиск по Ctrl-F, который хоть в ноутпаде есть :) И то, что не тормозило не только 15 лет назад, но и все 20 лет назад :D
 30.0.1599.10130.0.1599.101
+
-
edit
 

Balancer

администратор
★★★★☆

Mishka> Полный HTML и тогда не парсился быстро.

Локальные страницы на десяток килобайт HTML кода парсились за десятые доли секунды. Сегодня средний размер HTML вырос раз в 10, но и скорость процессоров выросла в 100 раз :) Собственно, любой «не-GPU» браузер открывает хоть мегабайтного размера страницу практически мгновенно. А стокилобайтную — ты и заметить не успеешь. Ну накой тут GPU?

Наконец, а есть точно информация, что тот же Хром, например, использует при парсинге HTML GPU? WebKit, ведь, движок, работающий без всяких GPU, автономная платформенно независимая библиотека.

Mishka> И тесты не совместимость не зря появились. :F

Так они для CSS появились. И не для парсинга, а для обработки результата парсинга. Совсем другая история.

Mishka> Вот и решили ускорить сканирование — типа маски построили и загрузили в GPU, а потом кормим поток строк

Всё хорошо, но все современные браузеры, кроме IE, используют платформенно-независимые движки. Какой GPU при работе с WebKit в командной строке сервера, на котором физически отсутствует драйвер видео?
 30.0.1599.10130.0.1599.101
+
0 (+1/-1)
-
edit
 

Nikita

аксакал

Balancer> s/3D/GPU/
Balancer> Что-то поменяется? :)

Да.

Balancer> Было б ещё понятно, в чём его открывать.

windbg, dumpchk, Visual Studio...

> MS и тут в своём репертуаре, неужели сложно в human readable что-то скинуть?

Я что-то пропустил ? Core dump в Linux уже стал human readable ?

Balancer> Один фиг, если не шашечки нужны, а чтобы ехало.

Э-э-э... Linux уже не едет ? :D
Учитесь читать.  9.09.0
+
-
edit
 

Mishka

модератор
★★☆
Balancer> Локальные страницы на десяток килобайт HTML кода парсились за десятые доли секунды. Сегодня средний размер HTML вырос раз в 10, но и скорость процессоров выросла в 100 раз :) Собственно, любой «не-GPU» браузер открывает хоть мегабайтного размера страницу практически мгновенно. А стокилобайтную — ты и заметить не успеешь. Ну накой тут GPU?


Если там контекстно-завсимыми грамматками описано, то это в общем случае может быть NP полная задача. И вырост на порядок приводит к увеличению времени экспоненциально. :) Поэтому скорость процев в 100 раз тут не канает.

Balancer> Наконец, а есть точно информация, что тот же Хром, например, использует при парсинге HTML GPU? WebKit, ведь, движок, работающий без всяких GPU, автономная платформенно независимая библиотека.

Без понятия. Я не смотрел на парсеры.

Balancer> Так они для CSS появились. И не для парсинга, а для обработки результата парсинга. Совсем другая история.

Для всего. В том числе и для CSS тоже. Реакция на некорректный HTML в совместимость тоже входит. А задача восстановления из синтаксической ошибки одна из самых сложных в парсинге.
 24.024.0
+
+5
-
edit
 

GOGI

старожил
★★★
Когда Mishka начинает рассуждать про программирование, у меня возникает такое необычное, восхитительное чувство что я полный идиот...
1  24.024.0
+
-1
-
edit
 

Balancer

администратор
★★★★☆

Mishka> Если там контекстно-завсимыми грамматками описано, то это в общем случае может быть NP полная задача. И вырост на порядок приводит к увеличению времени экспоненциально

Вроде, у парсеров давно уже сложность O(N). По крайней мере, 10Мб HTML 10 лет назад парсились за несколько секунд. А сейчас — за доли секунды. 15 лет назад оно бы тормозило сильно, но из-за процессора, а из-за нехватки памяти.

Mishka> Для всего. В том числе и для CSS тоже.

Повторюсь — речь не о парсинге, а об обработки. Парсить CSS даже куда проще, чем HTML, у него очень простая и однозначная грамматика. Вот потом на результат парсинга надо вызывать тонну сложных методов (в т.ч. и тех, где GPU реально востребован и работает), но к вопросу парсинга это отношения не имеет.

Mishka> Реакция на некорректный HTML в совместимость тоже входит. А задача восстановления из синтаксической ошибки одна из самых сложных в парсинге.

Реакция на некорректный HTML стандартами не описывается и в общем случае к радикальному, на порядки, усложнению парсера не приводит. Более того, никто парсер так усложнять не станет, так как реакция на некорректный HTML стандартами не описывается.
 2929

Mishka

модератор
★★☆
GOGI> Когда Mishka начинает рассуждать про программирование, у меня возникает такое необычное, восхитительное чувство что я полный идиот...
Просто я вживую сейчас общаюсь с заказчиком — Union Pacific. Ты не представляешь, чего они иногда хотят и придумывают... А потом, кто-то находится и делает маленькое RAD демо. И говорит — легко сделать... А потом... а потом — суп с котом. Хотя это никому было не нужно.
 24.024.0
+
-
edit
 

Mishka

модератор
★★☆
Balancer> Вроде, у парсеров давно уже сложность O(N). По крайней мере, 10Мб HTML 10 лет назад парсились за несколько секунд. А сейчас — за доли секунды. 15 лет назад оно бы тормозило сильно, но из-за процессора, а из-за нехватки памяти.

Ром, если ты имеешь ввиду лексический парсер, то да. А синтаксический очень сильно зависит от грамматик. 3 типа или регулярные выражения — тоже примерно так. Второго типа, или контекстно свободные, тоже так будут. Всякие LL(1), LR(1) — уже посложнее (контекст ограничен одним синтаксическим символом слева или справа). Если брать общие утверждение LL(n), LR(n), то там сложнее, возвраты могут быть наполную, но определяются глубиной контекста. В общем случае, когда просто грамматика типа 1 — полная попа. Насколько я знаю, HTML сочиняли не особо думая про парсеры.

Balancer> Повторюсь — речь не о парсинге, а об обработки. Парсить CSS даже куда проще, чем HTML, у него очень простая и однозначная грамматика. Вот потом на результат парсинга надо вызывать тонну сложных методов (в т.ч. и тех, где GPU реально востребован и работает), но к вопросу парсинга это отношения не имеет.

Проще? Может быть. Только по мнению W3C нужен LALR(1) механизм для нормального разбора — Grammar of CSS 2.1, т.е. контекстно-свободного механизма не хватает.

А обработка — да, там работы ещё хватает.

Balancer> Реакция на некорректный HTML стандартами не описывается и в общем случае к радикальному, на порядки, усложнению парсера не приводит. Более того, никто парсер так усложнять не станет, так как реакция на некорректный HTML стандартами не описывается.

Да, не описывается. И тому есть причины. :F Но жизнь может усложнить, т.к. некорректный HTML по стандарту не должен обрабатываться после нахождения ошибки. Но иметь поведение, как у ТурбоПаскаля никто не хочет. Потому все что-то своё делали.

Кстати, я ещё не видел формальное определение языка, которое бы предписывало поведение системы в ответ на синтаксическую ошибку. Ну кроме того, что надо бы показать, что ошибка была. А вот показать причину и где — этого уже не помню.
 24.024.0
+
-
edit
 

Nikita

аксакал

Balancer> Вроде, у парсеров давно уже сложность O(N)

Mishka уже написал о том, что есть парсеры, а есть парсеры.

Но про семантический анализ тоже не надо забывать. Это ведь самое интересное. А тут полный кирдык на всех фронтах. Например, любая приличная схема вывода типов имеет как минимум экспоненциальную сложность. И компиляторы кладутся на эту тему на счёт раз.
Учитесь читать.  9.09.0

Nikita

аксакал

Mishka> Проще? Может быть. Только по мнению W3C нужен LALR(1) механизм для нормального разбора

Да LALR(1) это просто замечательно. Можно сказать тривиально. Особенно в сравнении с грамматикой того же C++.
Учитесь читать.  9.09.0
+
-
edit
 

Balancer

администратор
★★★★☆

Nikita> Mishka уже написал о том, что есть парсеры, а есть парсеры.

Ладно, вернёмся от «шашечек» к «ехать». Что там с GPU в WebKit?
 30.0.1599.10130.0.1599.101
+
-
edit
 

Nikita

аксакал

Balancer> Ладно, вернёмся от «шашечек» к «ехать». Что там с GPU в WebKit?

С этим, пожалуйста, к Mishka. Это он парсит HTML на GPU.
Учитесь читать.  9.09.0

Mishka

модератор
★★☆
Nikita> Да LALR(1) это просто замечательно. Можно сказать тривиально. Особенно в сравнении с грамматикой того же C++.
Дык, я не спорю. :) Но единичка контекста уже нужна. Что усложняет.
 24.024.0
+
+1
-
edit
 

Mishka

модератор
★★☆
Nikita> С этим, пожалуйста, к Mishka. Это он парсит HTML на GPU.
Не, я не парсю. Но знаю людей, которые могли бы предложить такое. :F
 24.024.0
+
-
edit
 

Balancer

администратор
★★★★☆

Кстати, такой вопрос. Можно ли настроить Win8 так, чтобы на втором, мелком мониторе Metro-интерфейс оставался, когда на первичном крутятся классические приложения?
 30.0.1599.10130.0.1599.101
+
-
edit
 

Balancer

администратор
★★★★☆

Windows 8
Обновился, таки, до 8.1. Обновилось, в целом, шустро, всё же SSD, но четыре перезагрузки в процессе обновления меня впечатлили :D Кажется, такого ещё не было. После обновления же работает как и раньше, видимых изменений нет. Только прежние, одовлетворявшие меня как есть обои куда-то пропали и вместо них какой-то рыжий ужас в кубиках поставился. Пришлось лезть в настройки и ставить своё :)

// Транслировано с juick.com
 
?? Balancer #26.10.2013 01:42  @Balancer#26.10.2013 01:40
+
-
edit
 

Balancer

администратор
★★★★☆

Хм. В метро-интерфейсе цвета стали жесть какими ядовитыми :D


Зато решился только что интересовавший меня вопрос по одновременному использованию Метро и классического интерфейса на двух мониторах. Тут это работает. Пишу, вот, на первичном мониторе в классическом интерфейсе, а слева, на мелком — Метро:


А вот гаджеты почему-то не работают. Старые не загрузились, вызываю настройку — она не вызывается.
 30.0.1599.10130.0.1599.101
?? Balancer #26.10.2013 01:51  @Balancer#26.10.2013 01:40
+
-
edit
 

Balancer

администратор
★★★★☆

Шрифты стали меньше :eek:

Сперва не мог понять, что не так с восприятием стало, чуть хуже читается, чем раньше. Потом только дошло. Дисплеи стандартные, оба 96dpi. Залез в настройки, вытащил плавную настройку dpi — при 100% точно соответствует дюймовому шагу.

Вижу опцию «Изменять только размер текста», по идее, можно увеличить шрифты, оставив корректный dpi — фигушки, она не активна, выбрать нельзя.
 30.0.1599.10130.0.1599.101
+
0 (+1/-1)
-
edit
 

Kuznets

Клерк-старожил

Balancer> Хм. В метро-интерфейсе цвета стали жесть какими ядовитыми :D
Balancer> http://i.imgur.com/4FqbNqS.png

какой же убогий вид все-таки. эпоха "свободного пространства" как будто и не прошла лет 10 назад...
 24.024.0
+
+1 (+2/-1)
-
edit
 

stas27

эксперт
★☆
Balancer>> Хм. В метро-интерфейсе цвета стали жесть какими ядовитыми :D
Balancer>> http://i.imgur.com/4FqbNqS.png
Kuznets> какой же убогий вид все-таки. эпоха "свободного пространства" как будто и не прошла лет 10 назад...

Да уж, эта "новая" струя в IOS7 and Windows 8 мне лично кажется куда менее привлекательной, чем добрые тёплые ламповые иконки IOS6 и ниже и 7х форточек :(
С уважением, Стас.  30.0.1599.10130.0.1599.101
1 7 8 9 10 11 12 13

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru