Re[3]: Rust в Dropbox
От: rumit7  
Дата: 11.10.16 05:44
Оценка: +2
Здравствуйте, D. Mon, Вы писали:

DM>Автор пишет:

DM>

Увеличение производительности связано исключительно с алгоритмами. Rust даже немного медленнее плюсов.


Ну объективности ради, стоит привести и следующее предложение автора:

Но так как это личный проект — пишу на том, на чём удобно. А это Rust. От плюсов слишком много боли.


Хотя мне как плюсовику, его слова причиняют "слишком много боли"
Re[4]: Rust в Dropbox
От: so5team https://stiffstream.com
Дата: 11.10.16 06:03
Оценка: 4 (1) +3
Здравствуйте, rumit7, Вы писали:

R>Ну объективности ради, стоит привести и следующее предложение автора:

R>

Но так как это личный проект — пишу на том, на чём удобно. А это Rust. От плюсов слишком много боли.


R>Хотя мне как плюсовику, его слова причиняют "слишком много боли"


У автора svgcleaner специфический взгляд на C++, например, он принципиально не использует STL, плюс его опыт ограничен рамками работы с Qt и не сильно новыми версиями самого C++. Ну а если оставаться в рамках C++ with Classes, отказываться от STL и исключений, то да, боли будет гораздо больше и переход на Rust будет иметь смысл.
Re[4]: Rust в Dropbox
От: alex_public  
Дата: 11.10.16 07:05
Оценка:
Здравствуйте, flаt, Вы писали:

DM>>И весь GUI на С++, на расте лишь консольная часть.

F>Интересно, почему. Есть же gtk-rs, Qt, ещё что-то там.

В версии Qt для Rust (https://github.com/cyndis/qmlrs) имеется только убогий qml (аналог html на базе js движка), а собственно библиотеки нормальных виджетов нет. Оно и понятно. Для портирования qml достаточно добавить одну функцию вида "LoadQML", а для портирования библиотеки виджетов надо добавить сотни классов с тысячами методов...

Да, кстати, а GUI к обсуждаемому продукту (svgcleaner) написан как раз с помощью нормальных виджетов Qt: https://github.com/RazrFalcon/svgcleaner-gui/blob/master/src/mainwindow.h

Оффтопик. Увидел по ссылке на библиотеки Rust'а незнакомую мне GUI библиотеку (https://github.com/andlabs/libui) и пошёл посмотреть что там такое. Оказался крайне любопытный проект. Это кроссплатформенная (windows/osx/linux) GUI библиотека с нативными контролами, написанная на C, а не на C++. С точки зрения программиста на C++ тут естественно нет ничего интересного. А вот с точки зрения программистов Rust/D/Nim и других пока ещё маргинальных языков это может быть крайне важно. Потому как большинство из них страдают от отсутствия вменяемой GUI библиотеки и при этом все они позволяют бесшовно использовать C (но не C++, на котором сейчас написано практически всё приличное в этой области) библиотеки.

Единственно что надо ещё заметить, что проект с подобными целями следовало заводить как минимум лет 10 назад. А вот в 2016-ом году делать библиотеку без поддержки Андроида — это уже несколько сомнительное мероприятие. Понятно, что достучаться до нативных контролов из нативного кода на Андроиде весьма напряжно, но всё же вполне реально. Более того, можно тупо стащить базовые подходы (устройство универсальной java прокладки) из того же Qt, где это реализовано. Так что не знаю насчёт светлого будущего данного проекта. Но на месте Rust/D/Nim и т.п. программистов я бы активно следил и даже помогал данному проекту.
Re[5]: Rust в Dropbox
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 11.10.16 11:47
Оценка: 2 (1)
Здравствуйте, alex_public, Вы писали:

_>Оффтопик. Увидел по ссылке на библиотеки Rust'а незнакомую мне GUI библиотеку (https://github.com/andlabs/libui) и пошёл посмотреть что там такое. Оказался крайне любопытный проект. Это кроссплатформенная (windows/osx/linux) GUI библиотека с нативными контролами, написанная на C, а не на C++. С точки зрения программиста на C++ тут естественно нет ничего интересного. А вот с точки зрения программистов Rust/D/Nim и других пока ещё маргинальных языков это может быть крайне важно. Потому как большинство из них страдают от отсутствия вменяемой GUI библиотеки и при этом все они позволяют бесшовно использовать C (но не C++, на котором сейчас написано практически всё приличное в этой области) библиотеки.


Так по этой ссылке в разделе Language Bindings уже есть байндинги для всех упомянутых Rust/D/Nim.

А еще, если кто не видел:
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/
Там и Андроид, и даже текстовый режим!
Re[6]: Rust в Dropbox
От: alex_public  
Дата: 11.10.16 20:45
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Так по этой ссылке в разделе Language Bindings уже есть байндинги для всех упомянутых Rust/D/Nim.


Так я об этом и говорю. И наличие такого большого числа языков у только что рождённого проекта как раз и является следствием C интерфейса, потому что во многих языках подключение подобной библиотеки заключается в грубо говоря переименование h файла. В отличие от C++ GUI библиотек, для подключения которых надо писать прилично кода.

DM>А еще, если кто не видел:

DM>https://dlang.org/blog/2016/10/07/project-highlight-dlangui/
DM>Там и Андроид, и даже текстовый режим!

О, не видел. В то время, когда я игрался с D, данного проекта не было видно на горизонте. Судя по скриншотам очень не плохое решение. Тем более, что они похоже рисуют контролы сами, но при этом копируя системные (идеология Qt). Разве что скринов с Андроида не видно. Но если и там всё в порядке, то прямо уже так и тянет попробовать перевести какой-нибудь из GUI проектов на подобную библиотеку. А то Qt утомило уже своей монструозностью. Единственное что не хватает графического редактора форм для данной библиотеки.

И ещё слегка смущает тот факт, что они говорят о GUI библиотеки CoolReader'a, как о своём базисе. А при этом CoolReader в последних версиях вроде как (я им сам не пользуюсь, просто глянул на их сайте) перешёл на Qt. Хм хм)
Re[7]: Rust в Dropbox
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 12.10.16 04:08
Оценка: 4 (2)
Здравствуйте, alex_public, Вы писали:

DM>>А еще, если кто не видел:

DM>>https://dlang.org/blog/2016/10/07/project-highlight-dlangui/
DM>>Там и Андроид, и даже текстовый режим!

_>О, не видел. В то время, когда я игрался с D, данного проекта не было видно на горизонте. Судя по скриншотам очень не плохое решение. Тем более, что они похоже рисуют контролы сами, но при этом копируя системные (идеология Qt). Разве что скринов с Андроида не видно. Но если и там всё в порядке, то прямо уже так и тянет попробовать перевести какой-нибудь из GUI проектов на подобную библиотеку. А то Qt утомило уже своей монструозностью. Единственное что не хватает графического редактора форм для данной библиотеки.


Да, DLangUI что-то вроде года назад лишь возник.
Вместо графического редактора там есть редактор, где слева пишешь декларативное описание на DML, а справа тут же видишь, во что это воплощается.
Я этой весной один из главных продуктов своих перевел на D и DLangUI, впечатления весьма положительные.
см. http://www.infognition.com/VideoEnhancer/screenshots.html (Version 2)
Что порадовало по сравнению с монстрами вроде Qt, тут GUI библиотека добавляет меньше мегабайта к размеру exe-шника, линкуясь статически, и никаких DLL-ок вообще не нужно.
Отредактировано 12.10.2016 4:11 D. Mon . Предыдущая версия .
Re[8]: Rust в Dropbox
От: flаt  
Дата: 13.10.16 07:16
Оценка:
Здравствуйте, D. Mon, Вы писали:

DM>Я этой весной один из главных продуктов своих перевел на D и DLangUI, впечатления весьма положительные.

DM>см. http://www.infognition.com/VideoEnhancer/screenshots.html (Version 2)

Я слышал, что в DLangUI есть темы (скины), но на этих скринах софт выглядит как Linux в Windows.
Re[9]: Rust в Dropbox
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 13.10.16 12:02
Оценка: :)
Здравствуйте, flаt, Вы писали:

F>Я слышал, что в DLangUI есть темы (скины), но на этих скринах софт выглядит как Linux в Windows.


Да, есть темы. Дефолтные довольно самобытные (не совпадают с нативными нигде), здесь у меня своя тема. Если хочется условно нативного лука, надо делать соответствующую тему, готовой пока нет.
Проблема еще в том, что в той же винде уже с десяток разных стилей накопился, что считать нативнымт- непонятно. Например, на Win 8.1 функция WinAPI GetOpenFileName, если ей забыть один параметр передать, показывает такое:

Re[22]: Rust в Dropbox
От: vdimas Россия  
Дата: 17.10.16 14:30
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


Да большинство, от консольных утилит, то того же Notepad никакой полноты по Тьюрингу не требуют.
Re[23]: Rust в Dropbox
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.16 14:50
Оценка: -1
Здравствуйте, vdimas, Вы писали:

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


V>Да большинство, от консольных утилит, то того же Notepad никакой полноты по Тьюрингу не требуют.


Гипотетически — да, и не большинство, а 100%, с учетом конечной памяти вычислителя. А практически — хрен тебе.
Re[24]: Rust в Dropbox
От: vdimas Россия  
Дата: 17.10.16 19:00
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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

V>>Да большинство, от консольных утилит, то того же Notepad никакой полноты по Тьюрингу не требуют.

I>Гипотетически — да, и не большинство, а 100%, с учетом конечной памяти вычислителя. А практически — хрен тебе.


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

Пример задачи, где требуется "настоящая Тьюринг-машина" — парсер по контекстно-свободной грамматике.

Пример задачи, где НЕ требуется полноценный Тьюринг-вычислитель: текстовый редактор (без вложенных стилей, который), GUI-приложение (пусть будет приложение учёта финансов) да и вообще любая задача, выражаемая через эквивалентный конечный автомат или их систему, например, графические и физические игровые движки и игры на их основе.
Re[25]: Rust в Dropbox
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.10.16 10:33
Оценка:
Здравствуйте, vdimas, Вы писали:

V>А практически ты плаваешь в предмете, по-видимому, бо огромный пласт задач являются конечными, т.е. соответствующие им ф-ии — вычислимыми за конечное число шагов, т.е. никакая бесконечная лента этим задачам не нужна.


V>Пример задачи, где требуется "настоящая Тьюринг-машина" — парсер по контекстно-свободной грамматике.


Любой частный случай можно запилить на регулярной грамматике. Память то конечна, соответсвенно входных строк — конечное число. Бгг Ну будет у тебя астрономическое число вариантов, какая разница ?

V>Пример задачи, где НЕ требуется полноценный Тьюринг-вычислитель: текстовый редактор (без вложенных стилей, который), GUI-приложение (пусть будет приложение учёта финансов) да и вообще любая задача, выражаемая через эквивалентный конечный автомат или их систему, например, графические и физические игровые движки и игры на их основе.


Ога.
Re[22]: Rust в Dropbox
От: MaxxK  
Дата: 18.10.16 11:48
Оценка: 19 (3) +1
Здравствуйте, Ikemefula, Вы писали:

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


Пример реализации файловой системы, написанной в среде Coq, язык программирования для которой не является полным по Тьюрингу (с некоторыми оговорками, которые, насколько я могу сказать по итогам быстрого просмотра кода, в этом случае неактуальны).
Код также содержит доказательство того, что реализация ФС не потеряет ранее записанные данные при неожиданном отключении.

Статья: http://adam.chlipala.net/papers/FscqSOSP15/FscqSOSP15.pdf
Код: https://github.com/mit-pdos/fscq-impl

Для приведённых ранее примеров интерактивных приложений типа блокнота достаточно легко представить себе реализацию в виде набора обработчиков событий от пользователя, каждый из которых завершим на любых входах.
Отредактировано 18.10.2016 11:50 MaxxK (грамматика) . Предыдущая версия .
Re[23]: Rust в Dropbox
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.10.16 15:59
Оценка:
Здравствуйте, MaxxK, Вы писали:

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


MK>Пример реализации файловой системы, написанной в среде Coq, язык программирования для которой не является полным по Тьюрингу


А зачем так стараться ? Можно ведь вспомнить, что память компьютера конечна
Re[24]: Rust в Dropbox
От: MaxxK  
Дата: 18.10.16 19:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, MaxxK, Вы писали:


MK>>Пример реализации файловой системы, написанной в среде Coq, язык программирования для которой не является полным по Тьюрингу


I>А зачем так стараться ? Можно ведь вспомнить, что память компьютера конечна


... что, в свою очередь, ничуть не мешает программам в плохих случаях (1) уйти в бесконечный цикл или (2) съесть всю доступную память, так и не решив при этом задачу. От (1) Coq защищает по построению, а вот для (2) я, к сожалению, не слышал о каких-то красивых общих подходах.

А память компьютера — особенно с учётом доступа к сети — достаточно велика, чтобы для того самого большинства нужных на практике задач проще было считать её бесконечной (= больше, чем нужно для решения)
Re[25]: Rust в Dropbox
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 19.10.16 12:29
Оценка:
Здравствуйте, MaxxK, Вы писали:

MK>>>Пример реализации файловой системы, написанной в среде Coq, язык программирования для которой не является полным по Тьюрингу


I>>А зачем так стараться ? Можно ведь вспомнить, что память компьютера конечна


MK>... что, в свою очередь, ничуть не мешает программам в плохих случаях (1) уйти в бесконечный цикл или (2) съесть всю доступную память, так и не решив при этом задачу. От (1) Coq защищает по построению, а вот для (2) я, к сожалению, не слышал о каких-то красивых общих подходах.


И что с того ?
Re[26]: Rust в Dropbox
От: MaxxK  
Дата: 19.10.16 13:58
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, MaxxK, Вы писали:


MK>>... что, в свою очередь, ничуть не мешает программам в плохих случаях (1) уйти в бесконечный цикл или (2) съесть всю доступную память, так и не решив при этом задачу. От (1) Coq защищает по построению, а вот для (2) я, к сожалению, не слышал о каких-то красивых общих подходах.


I>И что с того ?


Не понял вопрос. Вот конкретный пример с Coq — отказались от Тьюринг-эквивалентности, и получился всё ещё достаточно мощный функциональный язык программирования, все программы, написанные на котором, гарантировано завершатся при достаточном количестве памяти. Но при этом понять, какого количества памяти будет достаточно, в общем случае для программ, написанных в Coq, нельзя. Так что это не серебряная пуля, даже при всех прочих возможностях Coq по написанию корректных по построению программ.
Re[27]: Rust в Dropbox
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 19.10.16 19:16
Оценка:
Здравствуйте, MaxxK, Вы писали:

MK>>>... что, в свою очередь, ничуть не мешает программам в плохих случаях (1) уйти в бесконечный цикл или (2) съесть всю доступную память, так и не решив при этом задачу. От (1) Coq защищает по построению, а вот для (2) я, к сожалению, не слышал о каких-то красивых общих подходах.


I>>И что с того ?


MK>Но при этом понять, какого количества памяти будет достаточно, в общем случае для программ, написанных в Coq, нельзя.


Ну вот ты сам себе дал объяснение. Потому утверждать "полнота по Тьюрингу не нужна" мягко говоря преждевременно. Пока что никто не продемонстрировал внятный инструмент, который решит насущные задачи нежели языки с полнотой по Тьюрингу. вот и всё.
Re[28]: Rust в Dropbox
От: MaxxK  
Дата: 19.10.16 21:14
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, MaxxK, Вы писали:


MK>>Но при этом понять, какого количества памяти будет достаточно, в общем случае для программ, написанных в Coq, нельзя.


I>Ну вот ты сам себе дал объяснение. Потому утверждать "полнота по Тьюрингу не нужна" мягко говоря преждевременно. Пока что никто не продемонстрировал внятный инструмент, который решит насущные задачи нежели языки с полнотой по Тьюрингу. вот и всё.


Почему преждевременно? Для программ «обычного человека» у нас есть характеристики корректности «наверное не упадёт», «наверное посчитает правильный ответ», «наверное не повиснет» и «наверное хватит памяти/стека». Для программ «курильщика Coq» эти характеристики — «точно не упадёт», «точно посчитает правильный ответ», «точно не повиснет», «наверное хватит памяти/стека». 3 гарантии из 4 (да даже 1 из 2, как в исходном примере), на мой взгляд, вполне себе повод для заявлений «полнота по Тьюрингу не нужна».

Если же порассуждать о том, как мог бы выглядеть внятный инструмент для доказательства характеристик по памяти, то неполные по Тьюрингу предметно-ориентированные языки с линейными (как в Rust) типами, или какая-то система и с линейными, и с зависимыми типами, мне кажутся многообещающими направлениями. Неполнота по Тьюрингу здесь появляется не сама по себе, а как необходимое условие корректной работы анализаторов кода.

Но пока у нас в production, к сожалению, не наступило светлое будущее даже с позиций избавления от стандартных ошибок при работе с памятью, не говоря уже о доказательствах корректности реализации алгоритмов. Поэтому (насколько видно мне, могу ошибаться) гораздо больше работ по извлечению пользы из Тьюринг-неполных языков публикуется именно по этим направлениям.
Re[29]: Rust в Dropbox
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 20.10.16 08:43
Оценка:
Здравствуйте, MaxxK, Вы писали:

MK>Почему преждевременно? Для программ «обычного человека» у нас есть характеристики корректности «наверное не упадёт», «наверное посчитает правильный ответ», «наверное не повиснет» и «наверное хватит памяти/стека». Для программ «курильщика Coq» эти характеристики — «точно не упадёт», «точно посчитает правильный ответ», «точно не повиснет», «наверное хватит памяти/стека». 3 гарантии из 4 (да даже 1 из 2, как в исходном примере), на мой взгляд, вполне себе повод для заявлений «полнота по Тьюрингу не нужна».


Теоретически, она не является необходимым условием. Ты это имел ввиду ? Я же говорю про экономическую целесообразность.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.