Таки разработчики решили эту проблему?

Здравствуйте, Аноним, Вы писали:

А>Таки разработчики решили эту проблему?

А была какая-то проблема? Что-то не заметил.

Сам gtk не позволяет работать более чем из одного потока. Так что gtk2hs тут ничем не поможет. Работа с GUI должна вестись в одной нити (и, если ничего не путаю, создавать виджеты можно в любой нити, добавлять/показывать только в основной).

unsafeInitGUIForThreadedRTS и, возможно, forkOS или runInBoundThread для GUI.

V>А была какая-то проблема? Что-то не заметил.

Ну как? Запуск mainGUI вызывал остановку работы всех легковесных потоков. Теперь это не происходит?

Здравствуйте, Аноним, Вы писали:

V>>А была какая-то проблема? Что-то не заметил.

А>Ну как? Запуск mainGUI вызывал остановку работы всех легковесных потоков. Теперь это не происходит?

Вроде и раньше не происходило. Попробуй forkOS mainGUI (а лучше forkOS всей ф-ии, которая занимается gui). У тебя какая версия ghc/gtk2hs и какая платформа? Под виндой помнится надо было для некоторых потоков (занимающихся I/O) делать forkOS (возможно, было бы достаточно только forkOS mainGUI, не проверял). Еще стоит скомпилить с опцией -threaded.

То есть, если я сделаю forkOS mainGUI, то я могу спокойно создавать легковесные потоки, которые не будут блокироваться mainGUI, однако доступ к GUI у меня будет только из потока где работает mainGUI?

Тогда такой вопрос: можно ли зарегистрировать в Gtk обработчик некого сигнала, который будет вызываться если я из другой нити буду посылать соответствующее сообщение, а уже обработчик некого сигнала в ните mainGUI, на основе полученной из сообщения информации будет модифицировать GUI?

Здравствуйте, Аноним, Вы писали:

А>То есть, если я сделаю forkOS mainGUI, то я могу спокойно создавать легковесные потоки, которые не будут блокироваться mainGUI, однако доступ к GUI у меня будет только из потока где работает mainGUI?

А>Тогда такой вопрос: можно ли зарегистрировать в Gtk обработчик некого сигнала, который будет вызываться если я из другой нити буду посылать соответствующее сообщение, а уже обработчик некого сигнала в ните mainGUI, на основе полученной из сообщения информации будет модифицировать GUI?

Фиг знает. У нас товарищ просто таймер повесил, который опрашивает канал от другого потока. Не очень красиво, но работает. Скорее всего в GTK такая фича есть, но сильно не искал.

Сейчас присматриваюсь к сигналу idle (или как он там?), который, обещают, будет дергаться когда ни чего не происходит + канал.

Здравствуйте, Аноним, Вы писали:

А>То есть, если я сделаю forkOS mainGUI, то я могу спокойно создавать легковесные потоки, которые не будут блокироваться mainGUI, однако доступ к GUI у меня будет только из потока где работает mainGUI?

А>Тогда такой вопрос: можно ли зарегистрировать в Gtk обработчик некого сигнала, который будет вызываться если я из другой нити буду посылать соответствующее сообщение, а уже обработчик некого сигнала в ните mainGUI, на основе полученной из сообщения информации будет модифицировать GUI?

1. см. подпись — проблем нет, можешь почитать исходники. -threaded, потоки создаю и с forkIO, и с forkOS — всё работает

2. в сам gtk2hs встроен готовый механизм посылки заданий gui thread — postGUISync / postGUIAsync. у меня например есть треды запускаемые по forkIO, отрабатывающие vbackground-задания, они используют эти вызовы для управления GUI

Я бегло посмотрел на исходники FreeArc, я так понял, что часть программы написана на Haskell, а часть на C. Чем обусловлен такой выбор? Почему не написать все на одном языке?

Здравствуйте, Аноним, Вы писали:

А>Я бегло посмотрел на исходники FreeArc, я так понял, что часть программы написана на Haskell, а часть на C. Чем обусловлен такой выбор? Почему не написать все на одном языке?

На Хаскелле проще написать сложную логику анализа входных файлов и выбора наиболее подходящих алгоритмов компрессии. Булат упоминал, что на Си/С++ такую логику он в разумные сроки просто не осили бы...

В свою очередь, переписывать готовые сторонние/стандартные алгоритмы компрессиии с Си/С++ на Хаскелл у Булата времени и нужды просто нет -- раз работают, так чего их трогать?

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

G>На Хаскелле проще написать сложную логику анализа входных файлов и выбора наиболее подходящих алгоритмов компрессии. Булат упоминал, что на Си/С++ такую логику он в разумные сроки просто не осили бы...

G>В свою очередь, переписывать готовые сторонние/стандартные алгоритмы компрессиии с Си/С++ на Хаскелл у Булата времени и нужды просто нет -- раз работают, так чего их трогать?

всё верно. плюс ещё низкая скорость хаскела

а gui часть я вообще предпочёл бы написать на .net, и возможно так и сделаю — при использовании простых типов данных импеданс между разными языками минимальный. заодно выйдет отличный пример грамотного испольщзования преимуществ каждой технологии — скорость c++, высокоуровневость хаскела, богатый инструментарий .net

BZ>плюс ещё низкая скорость хаскела

Интересно, а если переписать все на Haskell, во сколько раз уменьшится скорость?

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

BZ> а gui часть я вообще предпочёл бы написать на .net, и возможно так и сделаю

О, а можно поподробнее? Насколько я знаю, нет прямого биндинга к .NET (ну кроме HUGS98.NET, но это не очень серьёзно)...
Как Вы планируете это сделать? Интерфейс на С# (вариант -- F#/Nemerle), который вызывает dll-ку на Хаскелле? Или наоборот, основная прога на Хаскелле, вызывающая dll-ку .NET-а?
Или как-то ещё?

Здравствуйте, Аноним, Вы писали:

BZ>>плюс ещё низкая скорость хаскела

А>Интересно, а если переписать все на Haskell, во сколько раз уменьшится скорость?

если тебя интересует скорость хаскела (точнее, ghc), рекомендую:

An approach to fast arrays in Haskell [http://www.cse.unsw.edu.au/~chak/papers/afp-arrays.ps.gz]
Rewriting Haskell Strings [http://www.cse.unsw.edu.au/~dons/papers/fusion.pdf]

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

BZ>> а gui часть я вообще предпочёл бы написать на .net, и возможно так и сделаю
G>Как Вы планируете это сделать? Интерфейс на С# (вариант -- F#/Nemerle), который вызывает dll-ку на Хаскелле? Или наоборот, основная прога на Хаскелле, вызывающая dll-ку .NET-а?

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

собственно, главным опытом от реализации нынешнего GUI стало осознание того, что весь интрефейс между графической и архиваторной частью можно уложить в 10-20 процедур с простыми типами параметров, не сложнее строк

аналогочно этому, и интерфейс между архиватором и алгоритмами сжатия уложен в 20-30 вызовов и поэтому хаскел легко сопрягается с C++

кстати, если кому нужно — есть hsffig, автоматический генератор биндингов к чистом сишным (не C++) библиотекам. я не пробовал, но так понимаю, что с ним любая бибилиотека с чисто сишным интейесом может использоваться так же легко как родная (за исключением того, что сам интерфейс у сишной библиотеки по необходимости низкоуровневый, например никаких исключений — только коды разврата)