LINUX.ORG.RU

Началось формирование и тестирование сборок движка Servo

 ,


2

6

По сообщению разработчиков Mozilla, началось формирование ежедневных тестовых сборок браузерного движка Servo. Движок написан на языке Rust, тестовые сборки формируются для OS X и Linux 64bit, сборки для Windows и Android обещаются в самое ближайшее время.

В настоящее время, как сообщается, движок не полностью совместим с веб-стандартами и готов лишь для проведения тестирования и экспериментов.

На базе Servo предлагается браузер Browser.html с интерфейсом, полностью реализованным при помощи технологий HTML5. Данный браузер включён в ночные сборки и предлагается в качестве эталонного интерфейса для тестирования возможностей движка.

>>> Подробности (на английском языке)

★★★★★

Проверено: tailgunner ()
Последнее исправление: DeadEye (всего исправлений: 1)

Ответ на: комментарий от tailgunner

считать всех людей заскорузлыми дебилами - неправильно

У тебя совесть есть? Все интересное и хоть косвенно имеющее отношение к новости ты потёр как оффтопик и провокацию флейма, а сам с троллем-анонимусом десятую страницу какой-то нудной мути разводишь. Вы может уединитесь вдвоём где-нибудь и продолжите этот ваш увлекательный спор ни о чём?

mbivanyuk ★★★★★
() автор топика
Ответ на: комментарий от mbivanyuk

Вы может уединитесь вдвоём где-нибудь и продолжите этот ваш увлекательный спор ни о чём?

Сейчас он сольется на 1..size_y (писать или читать хоть какой-нибудь код для него непосильная задачи) и я сам уйду.

anonymous
()
Ответ на: комментарий от anonymous

Перечисли свои наработки в Rust, быстро и решительно.

let mut. Тебе хватит?

А ты не слезай с темы, ты говорил про «придумали».

«Придумывать - 1. Приходить к какому-л. решению в результате размышления, раздумья и т.п»

Какие-то проблемы?

Esper
()
Ответ на: комментарий от mbivanyuk

считать всех людей заскорузлыми дебилами - неправильно

У тебя совесть есть?

Да. Тебе отсыпать?

Все интересное и хоть косвенно имеющее отношение к новости ты потёр как оффтопик и провокацию флейма

Приведи, если не трудно, 3-4 ссылки на это «интересное». Я хочу учиться на своих ошибках.

а сам с троллем-анонимусом десятую страницу какой-то нудной мути разводишь

Вся эта «муть» имеет как минимум косвенное отношение к новости (обсуждение которой, кажется, завершилось).

Вы может уединитесь вдвоём где-нибудь и продолжите этот ваш увлекательный спор ни о чём?

Я не могу вынести подветку в отдельный топик :(

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Что забавно сам автор этого примера тут же и накосячил в коде на Rust:

Ну да, признаю. Впрочем, Си такую ошибку сделать не помешает. В своё оправдание могу сказать, что пишу посты быстро и временами отвлекаясь, а в рабочем коде так не косячил. И да, чего забавного-то?

Esper
()
Ответ на: комментарий от Esper

let mut. Тебе хватит?

Нет, т.к. это не новый синтаксис, это новое ключевое слово. Это тот же ML, где есть let и let rec.

anonymous
()
Ответ на: комментарий от anonymous

Ну вот ты и слился с примером для цикла

Когда продемонстрируешь желание учиться (хотя бы чтением соответствующего раздела Rust book), тогда твое мнение будет иметь хоть какую-то ценность.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Если ты хочешь доказать, что память - это ресурс, то я это написал еще до тебя. Объясни этим «людям», что во-первых они со своим Rust влезли не в тему, если хотели обсудить ARC...

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

Тот, что «попытки сделать безопасный язык» не должны упираться в работу с памятью, это должно быть частным случаем.

Memory safety - единственная проблема, путь решения которой более-менее ясен.

В-третьих Rust больше похож на маргинальный прикладной язык, у которого заменили GC на неудобную работу с памятью, чем на простой системный язык без GC.

Мне больше нравится ARC из Swift

***

во-вторых что ARC != RAII. В том числе потому, что он не exception-safe.

Тяжёлый случай...

anonymous
()
Ответ на: комментарий от anonymous

Нет, т.к. это не новый синтаксис, это новое ключевое слово.

Ключевые слова - не синтаксис?

Это тот же ML, где есть let и let rec.

Ты про val anon = ref "debilko"? Одинаковый синтаксис, прям не отличишь.

Esper
()
Ответ на: комментарий от shkolnick-kun

Правильно, он будет искать старые привычные инструменты

Это синдром утёнка, а не «правильно». Использовать старые парадигмы в новом языке, как минимум, глупо.

RazrFalcon ★★★★★
()
Ответ на: комментарий от anonymous

for i in 1..size_v {
for i in 1..size_v {}
}
Опс.

Что «опс»? Код верно отработает. А в плюсах будет выход за границу.

Что забавно сам автор этого примера тут же и накосячил в коде на Rust:

Нет там ошибки. Это валидный код.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от zaz

Как я себе вижу процесс разработки на RUST больших проектов...

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от tailgunner

тебе привели обычный код итерации по последовательности

Вообще, тут проблема, большей частью, не в отсутствии итерации по последовательности, а в необходимости рутинного и бестолкового написания названия одной и той же переменной три раза.

Он увидит, что в Rust есть итерация по последовательности и будет пользоваться только ей (это мой личный опыт с Python, если что)

Строго говоря, конкретно в Питоне всё же приходится иногда пользоваться индексами для итерации по массиву.

Неправильно. Вообще считать всех людей заскорузлыми дебилами - неправильно.

Ну, лично я частенько видел оригинальные способы итерации на Питоне. Вплоть до:

for i, _ in enumerate(array):
    print(array[i])

Походу, автор - бывший Гошник.

Но такое, надо признать, сильно не у всех.

Esper
()
Ответ на: комментарий от Esper

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

Для решения этой проблемы и делаются специальные синтаксические конструкции вроде «for переменная in итератор».

Строго говоря, конкретно в Питоне всё же приходится иногда пользоваться индексами для итерации по массиву.

Иногда. И enumerate иногда нужен. Но дефолтная конструкция - for.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Интересно, как новость о движке, скатилась в обсуждение ЯПов ?

А по тебе - здорово что мозилла таки здумала ремонт движка, плохо что на Rust. За названия команде пять ! :)

robot12 ★★★★★
()
Ответ на: комментарий от robot12

Интересно, как новость о движке, скатилась в обсуждение ЯПов ?

Так получилось, что конкретному набору людей интереснее обсуждать то, на чем браузер написан.

Хотя, конечно, интересно было бы про Graphene.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Вы серьёзно?

А почему нет? Это показывает интерес к языку. Понятное дело, что пока он молодой и не продвигается «насильно» как какой-нибудь свифт, то (очень) активного применения ждать наивно.

Ну и теперь ты скажи: серьёзно думаешь, что стековерфлоу решили таким образом раст продвигать? Зачем? Или к чему было вот эта часть про «апелляцию к эмоциям»?

DarkEld3r ★★★★★
()
Ответ на: комментарий от tailgunner

Это, ИМХО, сводит к нулю всю memory safety.

По моему, эта техника «используется», в основном, в аргументах всяких хейтеров.

DarkEld3r ★★★★★
()
Ответ на: комментарий от tailgunner

Для решения этой проблемы и делаются специальные синтаксические конструкции вроде «for переменная in итератор».

Так-то да. Но по сравнению с cишным for'ом даже паскалевский for i := 1 to n do - просто прекрасен. Был бы, если бы там была возможность менять шаг.

Esper
()
Ответ на: комментарий от DarkEld3r

По моему, эта техника «используется», в основном, в аргументах всяких хейтеров.

Точно нет. Совместное владение - больное место Rust.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

А как же bounds checking и arithmetic overflow check?
Но это всё, конечно же, относительно C/C++.

Согласен.

DarkEld3r ★★★★★
()
Ответ на: комментарий от robot12

Интересно, как новость о движке, скатилась в обсуждение ЯПов ?

На моей памяти, так было с новостями обо всех проектах на Rust. И, что характерно, сам Rust первыми упоминают хейтеры.

Esper
()
Ответ на: комментарий от anonymous

Конечному пользователю глубоко наплевать как именно выпала программа и что она при этом ему показала.

Зато ему не наплевать если данные, с которыми он работал, испортятся.

DarkEld3r ★★★★★
()
Последнее исправление: DarkEld3r (всего исправлений: 1)
Ответ на: комментарий от DarkEld3r

о кстати. Вчера накатал клиента своего протокольчика. И файлы, таки, попортил себе знатно (хорошо хоть бекапил до этого). И не потому что раст говно, а потому что писал не туда, куда нужно (.. и ..., да). Так что от попорченных данных ни раст ничто другое не спасет.

anonymous
()
Ответ на: комментарий от anonymous

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

Идиома «заметать мусор под ковёр» используется для других случаев, когда проблема остаётся, просто прячется. Аналогом использования GC является, например, глотание исключений.

А это просто фантазии. Люди прекрасно себе пишут на языках с GC/ARC, в то время как многие «парящиеся вопросами памяти» не могут оптимально и безопасно даже две строки сконкатенировать на С.

Не надо говорить про «многих» и «людей». Тем более не надо про «пишут», люди вон и на джаваскрипте пишут и некоторым даже нравится. Я привёл конкретные примеры проблемы, если есть красивые варианты решения без использования копирования и владения - прошу. Вообще, если нравится идея подсчёта ссылок - никто не мешает пользоваться в rust'е Rc<T>. Более того, так как rust следит за межпоточным доступом, подсчёт ссылок в Rc<T> обходится без блокировок и атомарных операций.

anonymous
()
Ответ на: комментарий от anonymous

А когда он не просто навороченный, а еще и у каждого свои импровизации и подходы, то следить за всем этим становится на порядок труднее.

С навороченностью понятно, хотя в расте, на мой взгляд, наоборот слишком уж увлекаются в погоне за «читабельностью» и «очевидностью».

А вот с второй частью не всё так однозначно. Если язык предоставляет какие-то механизмы, то их и используют. Если нет, то вынуждены изобретать каждый раз по своему. Ну как с ООП в С.

DarkEld3r ★★★★★
()
Ответ на: комментарий от tailgunner

Что не соответствует действительности? Что два разработчика сделали больше четверти всех коммитов? Что у одного из них закоммичено больше 2 миллионов строк кода? Что 6 человек из 163 сделали больше половины всех коммитов?

asaw ★★★★★
()
Ответ на: комментарий от Esper

И у тебя, конечно, есть примеры?

Примеры всегда найти можно. Скажем, можно (будет) перепутать .. и .... Или недавно видел весёлый пример: из-за опечатки в инициализации массива [0, 10] вместо [0; 10] «происходила фигня». Другой вопрос насколько реально и нужной с каждой такой мелочью бороться и какие от неё будут последствия.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Либо перегрузка операторов, либо развлечения со слабой динамической типизацией.

Esper
()
Ответ на: комментарий от asaw

Что не соответствует действительности?

Вот это:

asaw> Львиная доля кода уж точно написана парой разработчиков.

asaw> Да можно сказать вообще одним.

Что у одного из них закоммичено больше 2 миллионов строк кода?

А у одного - больше 7. Подозреваю, что это артефакт учета. Пара больших импортов, например.

Что 6 человек из 163 сделали больше половины всех коммитов?

Это уже ближе к делу, хотя не учитывает сравнительнуя сложность.

tailgunner ★★★★★
()
Ответ на: комментарий от DarkEld3r

А мне объяснишь?

Конечно.

http://en.cppreference.com/w/cpp/experimental/optional/operator*

«The behavior is undefined if *this does not contain a value»

Что нужно иметь в голове вместо мозгов, чтобы в 2016 году закладывать в библиотечный класс неопределенное поведение...

boost::optional

Насколько я вижу, там обещают assert. Тоже говно, но хоть не UB.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Ты можешь подозревать всё, что угодно. Это твои догадки. Твоя статистика их не подтверждает. Зато подтверждает мои утверждения, чего бы ты про них не писал.

asaw ★★★★★
()
Ответ на: комментарий от asaw

Ты можешь подозревать всё, что угодно. Это твои догадки

То есть комиттер с 7М строк добавленного кода и 88 коммитами никак не нарушает твою картину мира о том, что Servo написан другим человеком, который добавил в общей сложности ~1М строк? Ну окей.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Что нужно иметь в голове вместо мозгов, чтобы в 2016 году закладывать в библиотечный класс неопределенное поведение...

А там на этот счет такое вот пояснение (для умеющих читать)):

Notes
This operator does not check whether the optional contains a value. If checked access is needed, value() or value_or() may be used.

asaw ★★★★★
()
Ответ на: комментарий от asaw

А там на этот счет такое вот пояснение

Жаль, что там не написано «просто не делайте ошибки». Мы бы прочитали и больше их никогда-никогда не делали.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

твою картину мира о том, что Servo написан другим человеком, который добавил в общей сложности ~1М строк?

Повторю своё первоначальное утверждание:

Львиная доля кода уж точно написана парой разработчиков.

asaw ★★★★★
()
Ответ на: комментарий от tailgunner

Жаль, что там не написано «просто не делайте ошибки». Мы бы прочитали и больше их никогда-никогда не делали.

Ну посоветуй тогда авторам Rust выкинуть оттуда все unsafe фичи. Расскажи им про 2016 год)

asaw ★★★★★
()
Ответ на: комментарий от asaw

Повторю своё первоначальное утверждание:

Львиная доля кода уж точно написана парой разработчиков.

Повторю - я считаю твое утверждение ложным, а метрику, на основе которой оно сделано - ошибочной. Но, если ты, несмотря на приведенный факт комиттера с 7М строк и 88 коммитами, продолжаешь доверять этой метрике, да будет так.

tailgunner ★★★★★
()
Ответ на: комментарий от asaw

Ну посоветуй тогда авторам Rust выкинуть оттуда все unsafe фичи

Что такое, operator* можно употреблять только в unsafe-блоке или специально помеченном коде? Нет? Тогда о чем ты вообще.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Повторю - я считаю твое утверждение ложным, а метрику, на основе которой оно сделано - ошибочной.

На основе какой метрики оно по-твоему сделано? Вот есть один коммитер с 2 миллионами строк и 16% всех коммитов, и есть, допустим, коммитер с 7 миллионами строк, долей коммитов которого можно пренебречь. Как это опровергает мое утверждение о том, что львиная доля кода написана парой разработчиков?

asaw ★★★★★
()
Последнее исправление: asaw (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.