стабилизация API, это хорошо... Только вот, недавно решил обновить из транка, и выдает ошибку

evas_main.c: In function 'evas_new':
evas_main.c:161: error: too many arguments to function 'eina_array_step_set'

> Embryo - 1.0.0 ALPHA - интерпретатор языка Small

Интересно, почему вместо JavaScript/Python решили тащить низкоуровневую Си-подобную хренотень?

Ок, насчет «хренотени» я погорячился. Но все равно не понятно, зачем в составе DE нужна такая низкоуровневая штука.

http://www.compuphase.com/pawn/pawn.htm

ну наконец-то!

если и е в альфу войдет то это будет великолепно.

надо будет посмотреть что это за small, не поделится кто нить доками на русском или туториалом на simple english?

кастую в тред sda00

Модераторам

Пожалуйста, не удаляйте этот топик.

Если считаете альфа-верисю «не судьбоносной», и уверены что новость подтверждать не нужно, то перенесите ее в Talks.

Тэги хороши.

Возможно, заюзают для «внутренних нужд» DE?:)

>>Интересно, почему вместо JavaScript/Python решили тащить низкоуровневую Си-подобную хренотень?

Си - это офигенно :-)

Я честно говоря, не пользуюсь E17. Но когда копался в EFL - это просто манна небесная. Просто, красиво и приятно.

Кто в теме - Ecore/EFL вообще не позволяют использовать нити, или для этого существует какой-то стандартный трюк?

Не поклянусь, но вроде, они хорошо работают с обычными pthreads.

Или что? Какие именно трэды ты хочешь?

> Какие именно трэды ты хочешь?

В GUI.

Взято отсюда: http://trac.enlightenment.org/e/wiki/EFLChapterFive#s4

«Ecore chooses the Event-driven approach. Notice than in the case of uniprocessor systems, since only one control flow is active at a time, you never have true parallelism no matter the approach you choose.

[...]

If you still believe that threads are essential, you might not know that your X-Server is a single user-level process (no ties with the kernel OS) which handles all on screen drawing via Events. If a whole implementation of the X architecture is possible with events then certainly your application can refrain from using threads too.»

После этого начинаешь думать, что EWL (а может, и весь EFL) написан для single-threaded случая.

>>Notice than in the case of uniprocessor systems, since only one control flow is active at a time, you never have true parallelism no matter the approach you choose.

ну естественно. Один процессор - один поток.

>>Notice than in the case of uniprocessor systems, since only one control flow is active at a time, you never have true parallelism no matter the approach you choose.

ну естественно. Один процессор - один поток.

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

>>И кстати, в _любом_ (даже однопроцессорном) компьютере есть несколько устройств, которые работают физически параллельно (на этом основаны многозадачные ОС).

Я в курсе.

На счет EFL точно не в курсе.

Я не гуру программирования. А что тебе собственно, мешает callback'и в отдельных тредах пускать?

>>И кстати, в _любом_ (даже однопроцессорном) компьютере есть несколько устройств, которые работают физически параллельно (на этом основаны многозадачные ОС).

Я в курсе.

То есть ты понимешь, что размышления об отсуствии реального параллелизма на одном процессоре сомнительны? :)

А что тебе собственно, мешает callback'и в отдельных тредах пускать?

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

>>То есть ты понимешь, что размышления об отсуствии реального параллелизма на одном процессоре сомнительны? :)

Ну, растерман принимает иногда желаемое за действительное:-(

>Если считаете альфа-верисю «не судьбоносной»

Да люди юбилеи реже справляют, чем такие альфы выходят :)

как минимум поэтому новость нужно подтвердить...

>Кроме того, он потрясающе красив.

Отсыпь?

>Вероятно, стоит ожидать альфу E17 в обозримом будущем.

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

Кроме того, он потрясающе красив.

e16 красивее, а этот какой то никакой ...

Я, конечно, могу ошибаться, но, имхо, это т.н. «минорный релиз».

> Тэги хороши.

Поправили уже.

не такой уж он и минорный.... Это достаточно яркое событие )))

Переход с 0.99.xxxxx на 1.0.0 — это минорный релиз?

Теперь винде точно капец.

>Кто в теме - Ecore/EFL вообще не позволяют использовать нити, или для этого существует какой-то стандартный трюк?

Для синхронизации твоего потока с потоком UI (основным потоком приложения) можеш использовать ECore pipe. Колбек от пайпа будет синхронным с основным потоком EFL.

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

>ALPHA означает, что работы над API практически завершены. И этот API реализован.

Дай то Бог! Но что- то смутно терзает :)

Потрясающая альфа с вечно несовместимыми темами.

Беседы о enligthtenment с автором, начало тут:

http://www.mail-archive.com/community@lists.openmoko.org/msg54910.html

Рекомендую особо заценить:

http://www.mail-archive.com/community@lists.openmoko.org/msg54970.html

«evas and edje for example have caches to cache previously used data (fonts, images, caches scaled versions of images, edje groups and file content indexes etc.). it's a caching bonanza in there. the result its.. memory footprint will expand as the caches fill. e - every N seconds (see config dialogs for what it is set to there, but let's say 60 seconds) will flush caches. that means empty them out to make room for other apps if they need the memory.»

>>Кто в теме - Ecore/EFL вообще не позволяют использовать нити, или для этого существует какой-то стандартный трюк?

Для синхронизации твоего потока с потоком UI (основным потоком приложения) можеш использовать ECore pipe. Колбек от пайпа будет синхронным с основным потоком EFL.

Есть ли уже готовый пайп. специально предназначенный для передачи событий в main event loop из сторонних нитей?

и чё в Enlightenment красивого?

Это очень хорошо. Интересно, станут ли теперь появляться всякие «родные» пользовательские приложения для E.

Интересно, станут ли теперь появляться всякие «родные» пользовательские приложения для E.

Сомнительно. По-моему, лучшее что можно было бы сделать — слой совместимости с гтк.

Да какой же он красивый-то? Применили все принципы создания интерфейсов начала двухтысячных, но чуть усовременили.

>>сделать — слой совместимости с гтк

гтк

*_\

он потрясающе красив

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

>Есть ли уже готовый пайп. специально предназначенный для передачи событий в main event loop из сторонних нитей?

Нет, на сколько я знаю. А зачем?

Вобщем и целом архитектура EFL построена на прямом вызове функций и колбеках. Если ты имееш ввиду передачу сообщений окну, виджету и т.д, то в EFL вроде как этого нету. Может и не в тему, но на всякий случай.

>> Есть ли уже готовый пайп. специально предназначенный для передачи событий в main event loop из сторонних нитей?

Нет, на сколько я знаю. А зачем?

Чтобы рабочая нить могла сообщить о событии «я завершила работу» в нить GUI через стандартный механизм обработки событий.

>Применили все принципы создания интерфейсов начала двухтысячных, но чуть усовременили.

Ну... У EFL есть два жирнейших плюса:

1. Легковесность + портируемость (может даже с прицелом на embedded)

2. UI (скины, разметка, анимация) полностью отделён от кода by design (правда хорошего визуального редактора edc файлов мы можем и не дождаться)

А про внешний виде- так это «заслуга» не EFL а создателей скинов (см. п.2)

>Чтобы рабочая нить могла сообщить о событии «я завершила работу» в нить GUI через стандартный механизм обработки событий.

Смотри ecore_event_*(). Но я не уверен как там обстоят дела с многопоточностью. Мне в свое время пайпов хватило (там точно работало, если сейчас ничего не поменяли).

> e - every N seconds (see config dialogs for what it is set to there, but let's say 60 seconds) will flush caches

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

PS вместо тайм-стемпа нужно использовать счетчик поколений

>>Да какой же он красивый-то? Применили все принципы создания интерфейсов начала двухтысячных, но чуть усовременили.

Только там и были нормальыне интерфейсы.

В 90е были дичайшие извращения, вроде progman.exe, а в конце 2000х появилось несъедобная фигня вроде Aero, или KDE4.

> Только там и были нормальыне интерфейсы.

Нормальные таки были в конце девяностых, а потом пошла мода на уродливые текстурки, градиентики и объемные кнопочки. ё17 все это подхватил (:

Устарело, неуспев родиться.

Что там действительно круто - любые виджеты можно добавлять куда угодно. Хоть уровень заряда батареи на менюбар файлового менеджера. Такой себе конструктор.

Только деталек пока кот наплакал.

юзаю сабж из svn уже года 4, не меньше. Привык так, что все остальное вызывает аллергию :)

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

Не ради троллинга скажу, что я пробовал полгода назад Е17 в gentoo, из оверлея enlightenment кажется. Долго использовать не смог: пока пройду по всем диалогам настроек, получаю пару сегфолтов, настройки не сохраняются, и заново... В общем не долго у меня Е17 прожило. Но, как только оно станет постабильнее, обязательно попробую ещё раз. Работает шустро и довольно красиво. Если не сегфолтится. И ещё, не все дополнительные модули собирались, когда я Е17 пробовал.

>При каждом кэш-хите надо обновлять тайм-стемп ячейки кэша. Ячейки с протухшим тайм-стемпом вполне разумно херить.

PS вместо тайм-стемпа нужно использовать счетчик поколений

Не, вы не осознали глубины мысли, уважаемый.

Автор пишет «а вот мой E, понимаешь - зашибись для embedded, и памяти он кушает ну прямо меньше всех <данные о памяти>.» а потом оказывается что чудеса достигаются просто - мы просто выгружаем нафиг из памяти картинки от приложений которые например неактивны. и чудо наступает когда я хочу сделать task-switch, во время которого все это начитает грузиться с диска, разjpeg-иваться и тп заново.

Вообще E хорош анимацией. Если вам (как и мне) не нравится ожидать пока анимация завершится, или жалко мобильных ваттов на просмотр уползающих вдать тулбаров, или не нравиться что каждый фрем scrollable списков перерисовывается с нуля, смело забывайте про E.

> и чудо наступает когда я хочу сделать task-switch, во время которого все это начитает грузиться с диска, разjpeg-иваться и тп заново.

Если памяти мало, то лучше и правда считать файл заново, чем загонять систему в своп (привет oom-киллеру).

Если памяти много, то чтение будет из кэша ФС, а от разjpeg-ивания еще никто не умирал.