Objective Caml - Понедельник, 17 октября 2011

Objective Caml

ocaml@conference.jabber.ru

Понедельник, 17 октября 2011< ^ >

Конфигурация комнаты

Участники комнаты

GMT+4
[00:08:08] <gds> Kakadu: проблему понял, она весьма глубокая.  завтра попробую почесать репу.
[00:08:30] <Kakadu> gds: спасибо
[00:10:54] <gds> глубокая потому, что на каждый вызов не будешь же выделять по своему qObject -- подразумевается, что parent фиксированный, "по ссылке", управляет памятью сам, а не выделяет при вызове.  вот эта разница -- это плохо.  надо думать.
[00:12:50] <Kakadu> мне сильно хочется от камлёвых конструкторов отказаться
[00:13:03] arhibot вышел(а) из комнаты
[00:13:10] <Kakadu> пускай всё бы создавалось функциями create_classname_1... N
[00:16:20] <gds> а наследование как дальше?
[00:17:37] <Kakadu> понятия не имею. Получается надо тогда выставлять наружу функции, что создают [`qobject] obj
[00:21:47] <gds> можно попробовать оформить всё через извращённую weak hashtable, где по адресу QObject* parent искать адрес камлообъекта, ну и создавать его при нужде, зная тип parent'а.
[00:21:56] <gds> вот про это буду думать тоже.
[00:23:58] <Kakadu> мдя, ты знаешь толк в извращениях...
[00:29:30] <gds> это нужно для того, чтобы _не_ применять их.
[00:36:36] Typhon вышел(а) из комнаты: Replaced by new connection
[00:36:39] Typhon вошёл(а) в комнату
[00:37:08] <ygrek> gds: все так говорят :)
[00:38:41] <gds> ygrek: не применять их на практике в большинстве случаев.  уточнил.  но вот, однако, бывают случаи, когда нужно скрестить окамл и плюсы...
[00:44:39] gds вышел(а) из комнаты
[00:50:48] <ygrek> http://nponeccop.livejournal.com/223097.html
> convoluted foreign code interface
шорт побери, я в самом деле не понимаю, а где лучше?
[01:05:56] <Typhon> спросить надобно
[01:11:01] <ygrek> done
[01:29:08] Kakadu вышел(а) из комнаты
[02:09:33] ygrek вышел(а) из комнаты
[03:11:47] Typhon вышел(а) из комнаты
[03:37:18] letrec вошёл(а) в комнату
[04:46:52] letrec вышел(а) из комнаты
[07:12:36] zert вошёл(а) в комнату
[07:31:29] zert вышел(а) из комнаты
[09:57:25] gds вошёл(а) в комнату
[10:08:02] ermine вошёл(а) в комнату
[12:00:17] <f[x]> ребе ответил ссылками на папиры, которые как бы очень интересны, но в качестве практических примеров - не годятся
[12:29:18] klapaucius вошёл(а) в комнату
[12:37:49] Typhon вошёл(а) в комнату
[13:31:17] shaggie вошёл(а) в комнату
[13:41:25] komar вышел(а) из комнаты: Replaced by new connection
[13:41:26] komar вошёл(а) в комнату
[15:32:55] letrec вошёл(а) в комнату
[15:42:00] <ermine> так, центральный автомат интерпретилки грамматики сочинен, умеет аж 7 частей правил: CharTerminal, RangeTerminal, Opt, Star, Plus. Group, Alternate
[15:42:24] <ermine> код после вчерашнего конечно пришлос переписать нафиг, укоротив его более чем втрое
[15:43:22] <ermine> теперь как-то надо интерпретить грамматику, раскладывать по таблицам
[15:45:09] <ermine> gds: а как все же лучше семантику приделывать к грамматике? напободие PEG или наподобие yacc?
[15:50:18] <gds> ermine: да хрен его знает, если в целом.  А так -- семантика вроде примерно одинаково приделывается.  Есть правило, у него есть выдаваемый тип, вот и всё.
[15:52:35] <ermine> gds: правила alpha ::= [a-z], Name = alpha+, куда тут крепить семантику?
[15:54:28] <ermine> gds: в ocamlyacc ловят паттернами $1, $2, etc
[15:55:12] <gds> ясно куда: всякая хрень, что матчится alpha, имеет тип char.  name, соответственно List1.t char.  это если слишком плотно подходить к вопросу.  тебе же нужно и peg асилить, и кучу памяти не выделять при этом?
в ocamlyacc -- та же самая штука, вот попробуй сделать тип "лексема = char".  тоже будешь посимвольно коллекционировать.
[15:55:21] <ermine> ладно, надо чонить почитать
[15:55:32] <ermine> а пока буду именовать через доветочие группы
[17:15:13] Kakadu вошёл(а) в комнату
[17:16:04] <Kakadu> ура, я дома!
[17:24:02] <ermine> теперь заставят мыть посуду!
[17:24:39] <Kakadu> ненене
[17:26:06] <Kakadu> gds: что-нибудь есть новое про конструкторы?
[18:14:02] <gds> Kakadu: нет, было дофига других дел.  Помню, что что-то не заладилось, но был задолбан, поэтому решил оставить на потом, слава чатлогам.  Давай так: я дела доделаю (около часа-двух), вникну в проблему, затем отпишу в чятик.
[18:22:29] <f[x]> раньше не замечал, в bash'е есть completion для ocamlfind
[18:25:06] <ermine> Kakadu: а в qt совсем нет доклассовых функций?
[18:25:22] <Kakadu> ммм?
[18:25:49] <ermine> ну классы могли построиться на просто сишних функциях как в gtk
[18:27:01] <ermine> потом проще клепать классы, повторяя функционал кутишных классов, тогда нет проблем с наследованием
[18:29:14] <Kakadu> ну ты можешь вызвать какой-нибудь create_QObject_0'
[18:32:01] <ermine> ну это наверное проще чем биндиться к каждому классу
[18:34:27] <Kakadu> ну у меня фишка в том, что методы с щтрихом возвращают тупо указатель на объект. А потом я это заворачиваю в класс...
[18:35:18] <Kakadu> может ещё как-то можно поиграть  с 'a t. Возвращать не тупо [`qobject] t, а что-то в зависимости от класса объекта и засчёт этого мутить типизацию
[18:36:05] <Kakadu> ещё у меня есть идея, что некоторые классы-структуры надо отображать не в камлёвые классы, а в камлёвые модули, чтобы как-то попроще было
[18:36:17] ermine вспомнила свои мытарства с попыткой написать биндинг к berkeley db
[18:42:41] <ermine> ха, адриен собираешься мувить lablgtk2 в оазис
[18:43:31] <Kakadu> ermine: а там конструкторы у объектов есть?
[18:44:29] <ermine> он еще жалуется, что пытался нагадить в существующие мейкфейли и обломался
[18:46:49] <ermine> Kakadu: там два уровня: сначала сишние функции, потом классы, использующие в качестве методов эти функции, объекты - то что создают сишние функции-создатели, ну значит нет биндинга к объектам, если ты про методы у тех объектов
[18:47:12] <ermine> поэтому в общем получается стройно и красиво
[18:49:15] <ermine> а как переводить "could you kame a write up?"?
[18:56:41] <Kakadu> "можете ли описать подробнее" думаю
[18:57:18] <ermine> наверное
[18:57:29] <ermine> гугль не думает так
[18:58:05] ermine пошла имплементить Symbol
[19:00:44] <ermine> вообще что делать с грамматикой - относительно понятно: берем руле, его имя становится именем функции, а все остальное телом функции
[19:01:01] <ermine> вот надо пока к такому счастью стремиться
[19:13:21] <ermine> gds: ты там сильно занят? у меня тут есть один глупый флеймерский вопрос про потроха камла
[19:14:55] <ermine> видимо занят, подождем
[19:15:26] ermine сбегала за чам и реализует StringTerminal
[19:31:48] <gds> ermine: извени, я -- фифо.
[19:32:18] <gds> Kakadu: parent у QObject меняется?  может да / всегда нет?
[19:32:28] <ermine> gds: flood in, flood out?
[19:32:31] <gds> ну, фифо в плане не-работы
[19:32:57] <Kakadu> gds: может меняться
[19:32:58] <gds> ermine: ты не хочешь lablqt?  я -- хочу.  и вопрос висит уже порядка 20 часов.
[19:33:49] <gds> Kakadu: есть ли способ ассоциировать с плюсовым объедком какое-то "наше" значение?  Может у него есть фишки подобные, типа "private data"?  Где-то видел, не вспомню, где.
[19:34:08] <gds> ну, в tls видел, но это не то.
[19:35:01] <ermine> gds: лучше расскази, есть ли ньюансы оптимизации со связыванием переменных: конкретно - передавать IE_cont с функцией, у которой внутри куча связанных снаружи переменных, или это "по нагрузке/памяти" идентично, если бы их значения сначала скопировать в функцию?
[19:35:21] <ermine> ну как-то там, немного нескладно получилось, но вопрос про связывание переменных
[19:36:13] <f[x]> gds: http://doc.qt.nokia.com/stable/qobject.html#setProperty
[19:36:16] <gds> ermine: если я правильно помню, наличие внешних связанных тянет за собой внешнюю closure, но могу сильно ошибаться.
[19:36:42] <Kakadu> gds: Ну я передаю же как-то наш value _camlobject. Хотя я не совсем понял
[19:37:29] <f[x]> также можно половить рыбку в http://doc.qt.nokia.com/stable/qmetaobject.html
[19:37:54] <ermine> let len = String.length str in IE_cont (fun stream -> if i < len ...)
[19:38:06] <ermine> вот про len вопрос
[19:38:09] <Kakadu> f[x]: ну это для qobject'ов. всякие вещи типа QSize, QPointer ты предлагаешь во что отображать?
[19:38:21] <Kakadu> QPoint*
[19:38:34] <Kakadu> * --- это типа исправление, не указатель
[19:39:06] <ermine> шож все загалдели одновременно
[19:39:17] <f[x]> а не получится всякие такие вспомогательные объекты простыми туплами итп представить?
[19:39:31] <ermine> то все молчат сутками, то все сразу вместе пишут
[19:40:05] <Kakadu> f[x]: я думал что из таких простых объектов можно делать не камлёвые классы, а модуля с типами внутри
[19:40:43] <f[x]> угу
[19:41:15] <gds> f[x]: ты крут!  (в плане кругозора по практично-важным вещам.)  Только я туплю и сходу не понимаю, куда там присунуть.  Но это ещё почитаю.
[19:42:03] <f[x]> gds: просто во всех вменяемых сишных api есть место куда можно присунуть void* - специально для биндингов делается
[19:42:22] <gds> > ermine: вот про len вопрос
если тянешь только len, но не str, или есть хочешь гарантировать однократное вычисление len, то let len = ... in fun ... , весь механизм let-in за тебя.
[19:42:29] <f[x]> логично было предположить что в qt тоже есть :)
[19:42:49] <gds> > то все молчат сутками, то все сразу вместе пишут
гады, ага.
[19:43:23] <gds> f[x]: ты серьёзно предлагаешь модули лепить там, где естественным образом просится именно сраное оопшное наследование?  может не надо?
[19:44:33] <f[x]> ну я не вникал - мимо проходил
[19:44:40] <Kakadu> я думаю что даже самый злой кмлёвый программист наследоваться от QPoint не будет
[19:44:59] <f[x]> просто представить себе камлевое api где (int * int) будет объектом - ужас
[19:45:13] <gds> Kakadu: да, от QPoint -- навряд ли.  Но от QMidget -- вполне!
[19:45:32] <f[x]> gds: про qwidget речь не идёт
[19:46:02] <f[x]> развесистые gui-сущности с иерархиями - в объекты
[19:46:24] <Kakadu> gds: QWidget есть наследник QObject и унего есть поля метакласса вроде как
[19:46:25] <f[x]> утилитные маленькие сущности - в обычные типы
[19:46:27] <gds> f[x]: new tuple2(a,b) -- ну хз, можно.
[19:46:41] <Kakadu> только одна проблема
[19:46:42] <f[x]> и оверхедик нефиговый такой
[19:46:56] <f[x]> учитывая что эти qpoint'ы нужны наверное для рисования всяких полигонов
[19:46:57] <gds> в гуи оверхед не считают.
[19:47:05] <Kakadu> во что превращать QLayout? он же не QObject вроде
[19:47:29] <f[x]> вообще я за любой вариант который будет работать хоть как-нибудь!
[19:47:54] <gds> f[x]: во, а там для простоты нужна однотипность, да чтобы по-тупому было.
[19:48:12] <f[x]> разумно
[19:48:25] <Kakadu> Итак, 1й вопрос на повестке дня: как создавать камлёвые объекты? камлёвый конструктор, функция дергающая С++ или ещё что?
[19:48:53] <gds> Kakadu: главный вопрос тут -- не "как создавать", а "как не пересоздавать на каждый чих".
[19:50:58] <gds> как создавать -- примерно понятно.  Если метод parent возвращает QObject*, то надо таки создать камлокласс.  А в идеале -- запомнить сопоставление (QObject*, caml_obj_value).  Чтобы в случае перемены parent можно было бы замочить caml_obj_value, прописать новый QObject* и создать новый caml_obj_value.
[19:52:27] <Kakadu> gds: ты сейчас пытаешься съэкономить на создании камлёвого класса?
[19:53:34] <gds> на тысячах и миллионах созданий, да.  #parent будут дёргать часто, он же меняется.
[19:55:22] <Kakadu> gds: тогда получается что всякий метод надо так оптимизировать
[19:57:49] <gds> надо посмотреть точно, может и надо.  Если метод возвращает QSomeobject* -- думаю надо.  Если void, int -- не надо.
[19:58:18] <Kakadu> кажется у нас какие-то непонятки
[19:58:45] <Kakadu> gds: если при создании камлёвого объекта не будет дергаться сишный метод, то оверхеда не будет
[19:59:13] <Kakadu> если при создании камлёвого объекта будет дергаться сишный метод не _каждый_раз_, то оверхеда не будет
[19:59:45] <gds> а вдруг изменится значение, выдаваемое сишным parent?  пересоздавать камлообъект?
[20:00:46] <Kakadu> да
[20:01:22] <gds> то есть, надо дёргать сишный parent каждый раз, когда дёргают камловский #parent, хотя бы чтобы проверить, не изменился ли он.
[20:01:35] <Kakadu> да
[20:04:05] <Kakadu> думаю что если не смешивать камлёвые конструкторы с сишными, то даже наследование будет
[20:08:08] <gds> то есть, план таков: если возвращается QObject*, нужно в сишке дёргать this->parent(), брать из this->property("cppobj_parent") какой-то QVariant по его фиксированному имени, со значением, например
QVariant ( uint val )
или
QVariant ( qlonglong val )
, и смотреть, равен ли он полученному.  Если да -- брать this->property("camlobj_parent") и возвращать как результат.
Если не равен -- удалять привязку, создавать новый камловский qobject, связывать его и плюсовый объект через this->setProperty("..._parent", ...), и возвращать его.
[20:09:15] <f[x]> почему бы не смотреть property у сишного parent'а сразу?
[20:09:53] <Kakadu> я вообще не понял что gds сказал
[20:09:53] <f[x]> а старый маппинг удалять (разрегистрировать из рутов) в деструкторе
[20:10:00] <f[x]> лолед
[20:10:31] <f[x]> вопрос в том можно ли там присунуться в деструктор
[20:11:34] <gds> мда, факт, с деструктором туго.
[20:11:52] <Kakadu> вот мой текущий вариант:
по вызову метода, а ля QObect* parent() получает из сишечки какой есть указатель и создаем камлёвый объект нужного класса(создать сможем если все конструкторы хавают один параметр типа [`qobject] obj)
[20:12:07] <f[x]> не не
[20:12:27] <f[x]> сначала посмотреть в проперти это qobject есть ли там уже камлевый объект связанный
[20:12:30] <f[x]> и вернуть его
[20:12:41] <f[x]> иначе создать, привязать и вернуть
[20:12:56] <Kakadu> в чем профит?
[20:13:34] <f[x]> gds: там сигнал destroyed есть
[20:14:02] <gds> типа-подписка?  не вникал.
[20:14:29] <f[x]> угу
[20:14:52] <f[x]> Kakadu: профит в том что не надо аллокетить новый объект на каждый вызов
[20:15:03] <f[x]> плюс состояние можно хранить
[20:15:08] <f[x]> в камлевом объекте
[20:15:55] <Kakadu> f[x]: новый сишный, или новый камлёвый?
[20:16:02] <f[x]> камлевый
[20:16:36] <Kakadu> а не преждевременная ли это оптимизация?
[20:16:54] <f[x]> задача в чём - при появлении на горизонте сишного объекта - надо его связать с камлевым дуалом - при чём так что они оба друг про друга знают
[20:17:16] <f[x]> тогда сишный сможет передавать свои сигналы в камль, а камль сможет дёргать сишные методы
[20:17:33] <Kakadu> f[x]: мы вроде уже решили эту задачу...
[20:17:45] <Kakadu> https://github.com/Kakadu/lablqt/tree/master/inher
[20:17:53] <f[x]> соответственно на камлевой стороне это делается просто - т.к. мы её контролируем полностью, а на сишной стороне камлевый объект засовывается в проперти
[20:18:54] <f[x]> Kakadu: только я в inher не вижу собственно сишного объекта к которому ты привязываешься
[20:19:02] <f[x]> такого сишного объекта
[20:19:12] <f[x]> код которого ты не контролируешь
[20:19:47] <Kakadu> f[x]: Ктулху, хватит есть мой мозг!
[20:19:49] f[x] влез в левую тему и радостно раздаёт указания чего и как делать :)
[20:20:07] <Kakadu> вот твой объект: https://github.com/Kakadu/lablqt/blob/master/inher/A.h
[20:20:35] <f[x]> якщо вiн є!
[20:21:26] <Kakadu> gds: скажи что-нибудь
[20:22:06] <f[x]> а, даже так, типа миксин
[20:22:40] <f[x]> а что с объектами которые не ты создаёшь?
[20:22:56] <f[x]> т.е. ты дёргаешь parent и тебе приходит какой-то сишный объект
[20:23:07] <f[x]> на который есть референсы где-то внутри qt?
[20:23:20] <f[x]> ты в него так примиксоваться уже не сможешь
[20:23:23] <f[x]> вроде бы
[20:24:32] <Kakadu> блядь, действительно
[20:24:59] <Kakadu> lablqt пора закапыавть
[20:25:05] <Kakadu> всёравно нихера не получится
[20:26:22] <f[x]> calm down
[20:26:36] <f[x]> это обычная трабла в таких биндингах
[20:26:51] <f[x]> выше описал как это решается
[20:27:02] Typhon вышел(а) из комнаты
[20:27:12] <f[x]> calm down, caml up
[20:35:43] Typhon вошёл(а) в комнату
[20:45:24] <Kakadu> f[x]: положим объекты друг друга знают, что делать с наследованием на камлёвой стороне?
[20:46:47] <f[x]> обрисуй проблему
[20:47:36] <Kakadu> есть какой-то класс на камлёвой стороне и дуальный к нему на сишной. Хочется отнаследоваться на камлёвой стороне, чтобы переопределить некоторый метод
[20:48:00] <Kakadu> ну или неотнаследоваться и переопределить метод
[20:48:54] <f[x]> ну отнаследовался на камлевой стороне - все методы дёрнутые у такого экземпляра будут вызывать код из потомка если есть
[20:49:04] <f[x]> в чём трабл?
[20:49:52] <Kakadu> как сишная сторона узнает что метод переопределился?
[20:52:16] <f[x]> сишный объект смотрит в привязанный к нему камлевый объект и дёргает у него метод
[20:54:09] <Kakadu> цикла не будет?
[20:55:08] <Kakadu> сишная сторона вызывает камлёвый метод, а камлёвый этот же сишный
[20:55:25] <f[x]> ы?
[20:55:45] <f[x]> где-то разорвать его
[20:55:51] <f[x]> мелочи
[20:56:56] <Kakadu> я совсем запутался
[20:57:18] <Kakadu> я понял только то, что камлёвый объект надо хранить в свойствах
[20:58:28] <gds> f[x]: в /inher/ в том числе с наследованием разобрались, вроде.
[20:58:53] <Kakadu> gds: f[x] за 5 сек понял что мы лохи
[20:59:08] <gds> Kakadu: ну да.  а что, раньше не знал сего прискорбного факта?
[20:59:53] <f[x]> да, по наследованию из inher можно взять, там ортогонально, просто камлевый объект берётся из другого места
[21:00:02] <Kakadu> gds: что в inher жопа или что мы лохи?)
[21:00:04] <gds> но в /inher надо наследоваться в камле, а в QObject* parent -- просто помнить.
[21:04:14] <gds> Kakadu: в inher не жопа, но мы лохи, ясное дело.  inher -- нормальный таки.
[21:08:42] letrec вышел(а) из комнаты
[21:16:57] <gds> в принципе, было бы клёво реализовать обе модели единым образом, сведя их до property()/setProperty(), но я сейчас туплю и не могу понять, как это сделать так, чтобы даже галахический программист мог даже в шаббат кодить на lablqt.
[21:54:11] shaggie вышел(а) из комнаты
[22:10:57] Typhon вошёл(а) в комнату
[22:19:28] ermine вышел(а) из комнаты
[23:25:52] Typhon вышел(а) из комнаты: Replaced by new connection
[23:25:55] Typhon вошёл(а) в комнату
[23:47:19] gds вышел(а) из комнаты