Чувствую, что как-то общение между нами не задалось.
Вы читали спецификацию HTML? Птиченька-намёкенька.
Давайте почитаем как разные кодировки устроены. У вас точно HTML?
Но, в статье описано, более того, в коде можно посмотреть как реализовано у меня. Ещё Modest посмотрите (проект остановлен). Там, кстати, можно увидеть попытку с глифами и расчётом, наивную попытку.
Как-то это не согласуется с заявленной целью «самый быстрый HTML-парсер c DOM.»
Вы сомневаетесь? А вы потестируйте со своим. Ваш код в студию!
Блин, ну проблемы возникают у всех. А когда твоим продуктом пользуются N то любой малейший косяк сразу виден. Студия у них просто прекрасная, вообще у них много хорошего, чего вы их обижаете?! :)
Весь комментарий основан на предположениях и доводах. Я понимаю, что тебе что-то было очень сложно сделать, отрывки этого я вижу в твоих комментариях. Ты пишешь очевидные вещи. Ещё раз, движок есть, пишется чистовик. По мере написания компонентов будут выходить статьи. И будут статьи о всё "сексе" с глифами, расчетами.
Так же, я веслом не ударен, чтобы строить наивные предположения, что щас вот героически всех… Если посмотреть в мой профиль, то можно понять, что этим я занимаюсь больше 5 лет.
Про open source. Я работаю в компании которая занимается этим самым опен-сорсом — NGINX. Я чётко представляют, что это такое. Иллюзий нет, вообще, нет и не было. Мой проект есть и будет под лицензией Apache 2.0.
Чувак, как ты парсер то писал хтмл? Character token. Шучу :)
Статья про быстрый парсинг. Остальное будет.
И в завершении. Я реально рад, что есть такие проекты как ваш. Ваш проект придаёт уверенности и сил сделать свой движок. Некий буст.
Я вполне рад пообщаться с вами вне хабра. Всё же, почти, одно дело делаем.
Вы сейчас серьёзно? Прострелить ногу от того, что явно передаёшь размер данных?
Скажите это ребятам из MS, там вообще запрещают пользовать memcpy, заставляют использовать memcpy_s (с передачей размера). Смотрите описание.
В сях, правильным поведением является передача размера входных данных. Вы всегда можете сделать strlen() и компилятор оптимизирует.
Документация не полная, и зачастую пишется "второпях", но она есть и соответствует действительности.
Пошёл смотреть примеры и тут я заметил, что названия тегов, атрибутов и их значений передаются в функцию с их размером. Серьёзно?
Абсолютно серьёзно. Данные у вас могут быть не зануленными.
Или такими способом достигается перформанс?
Б — безопасность. В большинстве случаев компиляторы посчитают размер строки в момент компиляции, но часто мы имеем данные из буферов в рантайме, и часто данные не занулённые. При этом, если вы каждый раз будете пересчитывать строку, то да, о производительности такого кода говорить не стоит.
Об удобстве написания речь не идёт. Хотя, тут на вкус и цвет все фломастеры разные. Главное, чтобы использовать удобно было. Си именно даёт «Embedding API» из коробки. Не нужно делать двойную работу, проектировать дополнительный апи. Так же, все структуры видны. Я совершенно не противник плюсов, они мне даже нравятся, но данный проект именно на Си.
Желание встроиться в любой язык программирования у меня не вызывает вопросов. Тут, как раз, всё прозрачно. Я отлично понимаю (в NGINX сейчас тем и занимаюсь) как писать сишные расширения для Python, Node.js, Perl, PHP, Ruby и имею представление о Go.
Ну, слушайте, я вообще ещё не говорил о рисовалке. Тут, как говориться, ежу понятно, что она должна быть «hardware acceleration». Не открывая гугл, Skia вроде хром и лиса пользуют, говорят очень быстрая.
На данный момент стоит задача создания дерева отрисовки. Все расчеты, перерасчёты и так далее. При этом, делать всё это максимально быстро. Без рисования вообще. Но, сразу скажу, есть чёткое понимание как всё делать. Обсуждение бекенда рисовалки идёт постоянно. Приоткрывая занавес: у меня уже есть свой движок, всё что я выкладываю в публичный доступ это чистовик, черновик так и останется у меня.
P.S.:
Тысяча извинений. Из вашего сайта не понятно, что поддерживается, а что нет. Складывается впечатление, что как-то обрезано.
При этом, наши дороги немного расходятся. Не знаю насколько выгодно продавать лицензии, но я делаю open source, а деньги извлекать буду другим методом. Да и речь тут даже не о деньгах.
А сейчас как по вашему сделано? Сейчас реализован самый быстрый хтмл парсер из существующих с DOM. С основными DOM/HTML функциями в интерфейсам. При этом, интерфейсы используются все. Дальше, функции к всем существующим интерфейсам будут добавляться по мере надобности. Никто просто так не будет реализовывать все подряд функции DOM/HTML интерфейсов, это преждевременное занятие.
Сам посебе рендер не зависит от CSS/HTML парсера, он зависит от спецификаций как рендерить этот html.
Зависит, ещё как зависит. Расчеты и отрисовка HTML это есть итоговый комплекс парсинга и преобразований. Даже поведение отрисовки меняется в зависимости от html и css. Как он может не зависеть? Вы можете начать писать Layout без html, css, font (парсинг, расчеты глифов)?
То, что вы описали я могу сделать буквально сейчас используя свой Modest.
Разработчиков? Так если я сделаю все из говна и палок, при этом показывая как у меня что-то отрисовывается, люди использовать это не будут, это невозможно будет использовать. Потому как АПИ будет ломаться постоянно. Да и похвастаться чем? Скорость? Низким потреблением ресурсов? — нет, ничего этого не будет. Будут лишь какие-то огрызки, а потом чтобы привести эти огрызки в нормальный вид уйдёт ещё больше времени. Адаптировать чужое, часто, намного сложнее чем написать своё. Учитывая, что речь идёт именно о скорости.
Инвесторов? Я разговаривал с ~5 инвесторами. Люди хотели вложить в проект деньги, в разработку. Речи о "покажи нам картинку и тогда мы поверим" не шло. Отказал всем по разным причинам. В основном из-за расхождения целей.
Подход должен быть последовательный. Снизу вверх. Появляется новый модуль и его сразу же можно использовать. Использовать не только для браузерного движка, но и для других целей.
просто сделали рендер в той степени, в которой нам было нужно.
Какова эта степень этой простоты?
И CSS парсилку вы у кого-то взяли. Насколько быстро у вас всё это работает? Всё "органично" вписалось друг в друга? И работу со "сборкой мусора" вы написали. Он у вас динамически всё перерисовывает?
Речь идет о реализации быстрого браузерного движа. Если взять медленный и давно устаревший gumbo + прикрутить какой нибудь css парсер то речи о быстроте быть не может. Зачем писать рендеринг если вокруг все на соплях?
Нельзя начать с рендеринга не имея адекватного HTML/CSS/Font парсера. Тут закладываются основы. Это в CSS можно какие-то части делать, а какие-то нет. Там много «вторичного».
Энтузиазм не угрохается. Я занимаюсь этим не первый год.
Состоит оно из двух слов
1) lex — лексический (lexical). В линуксе даже программа такая есть, так и называется lex (лексический анализатор). Потому, что в браузерном движке много парсинга: html, css, font, url, js много всего.
2) bor — думаю тут и так всё ясно. Транслит нашего слова бор. Лесной бор. В начале хотел назвать lextree. Но потом, подумав, выбрал lexbor.
И уже потом, я осознал, что на GitHub у меня аккаунт lexborisov. То есть, начало от lexbor. В общем, сам Бог велел. Так и оставил.
myhtml тоже гляньте гласком. Прошлый проект.
Чувствую, что как-то общение между нами не задалось.
Вы читали спецификацию HTML? Птиченька-намёкенька.
Давайте почитаем как разные кодировки устроены. У вас точно HTML?
Но, в статье описано, более того, в коде можно посмотреть как реализовано у меня. Ещё Modest посмотрите (проект остановлен). Там, кстати, можно увидеть попытку с глифами и расчётом, наивную попытку.
Вы сомневаетесь? А вы потестируйте со своим. Ваш код в студию!
Блин, ну проблемы возникают у всех. А когда твоим продуктом пользуются N то любой малейший косяк сразу виден. Студия у них просто прекрасная, вообще у них много хорошего, чего вы их обижаете?! :)
Весь комментарий основан на предположениях и доводах. Я понимаю, что тебе что-то было очень сложно сделать, отрывки этого я вижу в твоих комментариях. Ты пишешь очевидные вещи. Ещё раз, движок есть, пишется чистовик. По мере написания компонентов будут выходить статьи. И будут статьи о всё "сексе" с глифами, расчетами.
Так же, я веслом не ударен, чтобы строить наивные предположения, что щас вот героически всех… Если посмотреть в мой профиль, то можно понять, что этим я занимаюсь больше 5 лет.
Про open source. Я работаю в компании которая занимается этим самым опен-сорсом — NGINX. Я чётко представляют, что это такое. Иллюзий нет, вообще, нет и не было. Мой проект есть и будет под лицензией Apache 2.0.
Чувак, как ты парсер то писал хтмл? Character token. Шучу :)
Статья про быстрый парсинг. Остальное будет.
И в завершении. Я реально рад, что есть такие проекты как ваш. Ваш проект придаёт уверенности и сил сделать свой движок. Некий буст.
Я вполне рад пообщаться с вами вне хабра. Всё же, почти, одно дело делаем.
Там есть документация, она на сайте. Выше написал об этом.
В тестах можно посмотреть, но лучше в доку или в примеры.
Вы сейчас серьёзно? Прострелить ногу от того, что явно передаёшь размер данных?
Скажите это ребятам из MS, там вообще запрещают пользовать memcpy, заставляют использовать memcpy_s (с передачей размера). Смотрите описание.
В сях, правильным поведением является передача размера входных данных. Вы всегда можете сделать strlen() и компилятор оптимизирует.
Разве нет? Или вот тут.
Документация не полная, и зачастую пишется "второпях", но она есть и соответствует действительности.
Абсолютно серьёзно. Данные у вас могут быть не зануленными.
Б — безопасность. В большинстве случаев компиляторы посчитают размер строки в момент компиляции, но часто мы имеем данные из буферов в рантайме, и часто данные не занулённые. При этом, если вы каждый раз будете пересчитывать строку, то да, о производительности такого кода говорить не стоит.
Об удобстве написания речь не идёт. Хотя, тут на вкус и цвет все фломастеры разные. Главное, чтобы использовать удобно было. Си именно даёт «Embedding API» из коробки. Не нужно делать двойную работу, проектировать дополнительный апи. Так же, все структуры видны. Я совершенно не противник плюсов, они мне даже нравятся, но данный проект именно на Си.
Желание встроиться в любой язык программирования у меня не вызывает вопросов. Тут, как раз, всё прозрачно. Я отлично понимаю (в NGINX сейчас тем и занимаюсь) как писать сишные расширения для Python, Node.js, Perl, PHP, Ruby и имею представление о Go.
Ну, слушайте, я вообще ещё не говорил о рисовалке. Тут, как говориться, ежу понятно, что она должна быть «hardware acceleration». Не открывая гугл, Skia вроде хром и лиса пользуют, говорят очень быстрая.
На данный момент стоит задача создания дерева отрисовки. Все расчеты, перерасчёты и так далее. При этом, делать всё это максимально быстро. Без рисования вообще. Но, сразу скажу, есть чёткое понимание как всё делать. Обсуждение бекенда рисовалки идёт постоянно. Приоткрывая занавес: у меня уже есть свой движок, всё что я выкладываю в публичный доступ это чистовик, черновик так и останется у меня.
P.S.:
Тысяча извинений. Из вашего сайта не понятно, что поддерживается, а что нет. Складывается впечатление, что как-то обрезано.
При этом, наши дороги немного расходятся. Не знаю насколько выгодно продавать лицензии, но я делаю open source, а деньги извлекать буду другим методом. Да и речь тут даже не о деньгах.
Ваше мнение очень важно для нас.
Следите за обновлениями и всё узнаете.
Я вас услышал.
Если вам что-то не нужно, это не значит, что это не надо остальным.
Много, даже деньги платят за биндинги и доработки. И благодарности, что вместо 20 серверов теперь используют 8. Смотрите на myhtml.
В общем, я вас понял.
Зависит, ещё как зависит. Расчеты и отрисовка HTML это есть итоговый комплекс парсинга и преобразований. Даже поведение отрисовки меняется в зависимости от html и css. Как он может не зависеть? Вы можете начать писать Layout без html, css, font (парсинг, расчеты глифов)?
То, что вы описали я могу сделать буквально сейчас используя свой Modest.
Внимание кого? Ответьте на этот вопрос.
Подход должен быть последовательный. Снизу вверх. Появляется новый модуль и его сразу же можно использовать. Использовать не только для браузерного движка, но и для других целей.
Какова эта степень этой простоты?
И CSS парсилку вы у кого-то взяли. Насколько быстро у вас всё это работает? Всё "органично" вписалось друг в друга? И работу со "сборкой мусора" вы написали. Он у вас динамически всё перерисовывает?
Речь идет о реализации быстрого браузерного движа. Если взять медленный и давно устаревший gumbo + прикрутить какой нибудь css парсер то речи о быстроте быть не может. Зачем писать рендеринг если вокруг все на соплях?
Энтузиазм не угрохается. Я занимаюсь этим не первый год.
При этом, вы сильно утрируете (доводите до абсурда), вы бы ещё, для примера, объединили арабскую вязь и иероглифы.
1) lex — лексический (lexical). В линуксе даже программа такая есть, так и называется lex (лексический анализатор). Потому, что в браузерном движке много парсинга: html, css, font, url, js много всего.
2) bor — думаю тут и так всё ясно. Транслит нашего слова бор. Лесной бор. В начале хотел назвать lextree. Но потом, подумав, выбрал lexbor.
И уже потом, я осознал, что на GitHub у меня аккаунт lexborisov. То есть, начало от lexbor. В общем, сам Бог велел. Так и оставил.