LINUX.ORG.RU

Приглашаю помочь мне в разработке vala-panel

 , , ,


1

4

Мне зело лень переписывать её на C (ну и заодно производить разделение классов). Если кто-то хочет поучаствовать - милости прошу. И ещё - моя панель заслуживает на ЛОР хотя бы мини-новостей?

★★

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

Никаких ++, особенно на Gtk. Зачееееем? Ну и апплеты все равно на vala останутся

Athor ★★
() автор топика

This is Vala rewrite of SimplePanel, GTK3 LXPanel fork.

Т.е. теперь будет:
This is a partial C rewrite of a partially rewritten in Vala SimplePanel, GTK3 LXPanel fork.

Хм.

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

Не, там от lxpanel уже почти ничего не осталось. Буквально пару дней назад закопал раннер, заменив его новым. Api апплетов у меня полностью изменено. От lxpanel там только трей и алгоритм позиционирования.

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

А зачем вообще на Си переписывать? Я наоборот за то, чтобы код на Си, использующий GLib и GObject переписывать на Vala.

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

Если это всё из-за недавней дискуссии в мэйлинглисте vala, то по итогам дискуссии там наоборот решили, что язык жив.

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

Не, не только по ней. Изначально была дискуссия в багтрекере budgie-desktop. Домой приду - кину ссыль

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

Официальное мнение разработчика:

The codebase has begun to grow out of control..

With Vala we find many odd runtime issues, constant issues between new vapi files, an excessively heavy approach to the heap, poor debugging, poor maintainability, and frankly utterly shite C code that is emitted.

Even with those items out of the way, things to consider:

We use a seriously limited set of CFLAGS to build all Vala elements in Budgie Desktop. Given that it generates C code, this code is not actually subject to strict compiler flags, and poses security risks. We cannot enforce PIE/RELRO properly, again because the resulting code buckles (Solus employs full relro (bind now) by default) There are over 400 bugs encountered by static analysis in the generated C code, some of them having the potential to grow into critical bugs I'm good at C, I don't need a translator... Stable ABI: Completely SOL with Vala as we cannot access GCC attributes, so must rely only on linker scripts, without the ability to correctly track ABI changes. The code is horrifically inefficient. Vala is a complete heap-whore, ignoring stack space and copying All The Things, and explicitly copying things living in .text. No proper tooling around Vala for any form of real world continuous integration or code formatting (clang-format..) In many, many situations, we've been completely roadblocked because Vala isn't advanced enough to speak the level of C we need, i.e. dealing with long transfers via X atoms (bitwise shift isn't a strength here.). At the end of the day, it's not a real programming language. It's translated into C and then the compiler does the real work, if it was even interpreted or contained its own toolchain based on LLVM then we wouldn't have half of these issues, as it stands, it's a translator.

It's been spoken about for a while to do the C rewrite, now lets schedule this as a base requirement for the next major Budgie release, and rip all the shit out of the codebase

Right now we're busting at the seams with non-interoptable crap:

Totals grouped by language (dominant language first): vala: 10183 (53.34%) ansic: 8502 (44.54%) xml: 308 (1.61%) sh: 96 (0.50%)

Total Physical Source Lines of Code (SLOC) = 19,089 Development Effort Estimate, Person-Years (Person-Months) = 4.42 (53.09) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.94 (11.31) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 4.69 Total Estimated Cost to Develop = $ 597,673 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler

Requirements going forward:

Travis CI for all PRs Require all C code to comply with our .clang-format configuration, with absolutely no exceptions. Enforce heavier CFLAG requirements and respect distributionCFLAGS fully. Drop ALL Vala code from the core of Budgie - no more Vala additions will be accepted now. Bump the ABI to become incompatible with the current 10.2 branch of Budgie (intentionally)

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

если быть кратким: «на 3 день» (с) хипсторы обноружили, что очередной хипстерский суперязычок оказался непроработанным говном, непригодным дажЫ для хипсторских поделок. Хипсторы заплакали и ушли в свои айфоны... Пришлось вернуться на пестон 😣 Невиданная история, Сэры.

mos ★★☆☆☆
()

Внесу свою лепту: не нужно.

entefeed ☆☆☆
()
Ответ на: комментарий от Athor

Официальное мнение разработчика:

Ну там по большей части мнение.
Надо просто понимать, что язык не самый распространенный, а потому количество тулзов вокруг него весьма ограниченное, с этим приходится мириться.
Зато не писать вручную наследования, свойства, исключения, деструкторы, что на Си выливается в много кода,
а Си ABI + Си API + GObjectIntrospection с их уникальной гибкостью при этом остаются.
Если же писать на C++/Питоне/Rust/etc, то и все замыкается автоматом на одном языке.

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

-Wall -Wextra -pedantic.

Там что-то конкретное смущает или просто обилие предупреждений (что для vala всегда было нормальной ситуацией)?

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

Согласен с тобой. Но тут не только в тулзах дело. У меня в vala-panel в vala-части кода около 100 C Warnings. В C коде - ни одной:) (с -Wpedantic появятся скорее всего, но мало).

А касательно

Зато не писать вручную наследования, свойства, исключения, деструкторы, что на Си выливается в много кода, а Си ABI + Си API + GObjectIntrospection с их уникальной гибкостью при этом остаются.

смотри мой пост там же:

writing C boilerplate makes me boring. Is there any tools to automate its writing? And Vala gives to us many convenient functions like DBus annotation (whole interface without XML), GtkTemplate annotation (very convenient template automation) and some smaller. Rewriting it in C is painful, very painful. But benefical.

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

Как минимум обилие предупреждений. Еще приходится очень сильно извращаться с xcb в extras и носить с собой файл gio-addons.vapi, в котором определены функции GLib, отсутствующие в официальных vapi, к примеру g_keyfile_settings_backend_new

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

И еще течь. Почему-то это все течет просто адски, причем именно в still reachable. И если в C еще можно как-то поиграться с памятью, то в Vala - фиг-то там.

Athor ★★
() автор топика

Что за день сегодня, нерабочая плата пришла, Валу закапывают...

backbone ★★★★★
()

дайте хоть на скриншоты посмотреть, чтоль. А то гугл выдает дичЬ, а ставить чтоб увидеть лениво. Пейсал свою панельку от нех делать на GTK, мож пригодится что.

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

Я бы на твоем месте лучше Валю пилил. Чтоб и предупреждения убрать, и функции добавить.

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

Тут на ЛОР в архивах были:-)

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

Да как так можно-то?!

Вон, Plank на Vala написан и работает просто отлично и быстро.

Лучше бы QML закопали или сделали такую же фичу, как и у Vala: компилятор в C или C++.

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

Лучше бы QML закопали

++

Разделяю недоумение по поводу Vala. Казалось очень неплохим решением в 2010, но стагнировало

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

Что делать?

Вернуться к истокам: Си. C учетом опыта прожитых лет, примерно сформулированных https://matt.sh/howto-c , как-то так.

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

Да сам не очень представляю. Полагаю, что если нужен GUI и высокая производительность, то кроме C++ или C особых вариантов-то и нет (разве что под macOS и iOS это будут Objective-C и Swift).

Если вопрос производительности остро не стоит, что диапазон вариантов более чем широк: начиная от скриптоты (вроде Tcl/Tk или Python-ов с Ruby-ями с биндингами к Qt), заканчивая Java. Включая сюда и такое порождение человеческой мысли, как Electron (Chromium+JS+Node.js, но для десктопа).

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

Спасибо, не надо. Большинство фич нереализуемо на нем.

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

А на чем сейчас можно гуй писать?

На тикле, например.

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

GUI и высокая производительность, то кроме C++ или C особых вариантов-то и нет

Лолшто? Gtk гуй на расте прекрасно пишется, слава GI.

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

И хороших примеров этого можно увидеть буквально на каждом шагу?

Я это к тому, что в мире не так много любителей бегать по граблям, коих множество в любой молодой технологии (коей и является GUI на Rust-е).

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

И хороших примеров этого можно увидеть буквально на каждом шагу?

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

Сам биндинг там генерится как и везде с помощью GIR, который уже оттестирован по самое ``не могу".

что в мире не так много любителей бегать по граблям

И это говорит человек, который посоветовал свифт, сишку и тикль с тк. Там-то нет граблей, особенно в тк — такой-то тулкит: адовый колбэкхэл и виджеты работают не так, как того от них ожидаешь.

Последовательный, че. С гткмм ты по граблям не меньше бегать будешь с RefPtr-ами и багами реализации. Как и на чистом сишном гтк.

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

И это говорит человек, который посоветовал свифт, сишку и тикль с тк.

Опыт использования этих языков в реальной разработке будет сильно побольше, чем Rust-а и Rust-овых биндингов. Даже у Swift-а.

Но фанаты Rust-а вольны бегать по граблям сколько им вздумается.

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

будет сильно побольше, чем Rust-а и Rust-овых биндингов. Даже у Swift-а.

И много у тебя опыта в разработке на тикле со свифтом? В свифте до сих пор синтаксис перелопачивают, какое там разработка. В тикле/тк до сих пор entry фокус тупо не работает. Но грабли, разумеется, в расте. Тебе с дивана виднее, че.

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

И много у тебя опыта в разработке на тикле со свифтом?

У меня нет ни того, ни другого. Но это никак не влияет на тот факт, что в Интернете документации и пр. материалов для Tcl/Tk и для Swift-а, а так же готовых библиотек для них, в разы больше, чем для любого из биндингов Rust-а к любой GUI библиотеке.

Грабли есть везде, но в молодых технологиях, к коим относится Rust и Rust-овые биндинги, их просто-напросто больше. Плюс, у молодых технологий есть такой риск оказаться заброшенным, когда интерес у основных мейнтейнеров иссякнет. Мы как раз находимся в теме, которая возникла из-за невнятных перспектив Vala.

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

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

что в Интернете документации и пр. материалов для Tcl/Tk и для Swift-а, а так же готовых библиотек для них, в разы больше, чем для любого из биндингов Rust-а к любой GUI библиотеке.

Мой диванометр зашкалило. Готовых библиотек для раста, наверное, более, чем для тикля и свифта вместе взятых. Загляни хоть в карго, а потом посмотри на то, что есть для свифта и тк, и не говори больше таких глупостей.

из-за невнятных перспектив Vala

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

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

Готовых библиотек для раста, наверное, более, чем для тикля

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

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

результат не одного года разработки

готовые качественные библиотеки

Ну на тикле их, обычно, просто нет. Даже тк — редкостное говно, по сути. И годы ему как-то не помогли.

А почему?

результат не одного года разработки

А потому что ты забыл, что время разработки измеряется не в часах, а в человекочасах. Если у тебя комьюнити в три инвалида, как в тк или вале, то никакие годы не помогут.

Freyr69 ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.