VS
Надо не GUI-приложения писать, а графический движок, и GUI уже как его производную.
Size: a a a
2019 May 18
AZ
Надо не GUI-приложения писать, а графический движок, и GUI уже как его производную.
Так напиши :)
AZ
Насколько я понял из описания чтобы выполнить функцию и при этом не "замораживать" gui надо поднять два Чикена. Печально. Это конечно тоже вариант, но как это все сделать кроссплатформенно
P1
Народ, а кто-нибудь шарит в Racket'овских макросах? Я тут написал почти первый в жизни макрос, хотелось бы, чтобы кто-нибудь подсказал, можно ли лучше, ну и вообще покритиковал. Код вот https://codereview.stackexchange.com/q/220055/19346
сложно сходу понять, получился довольно запутаный код, но для такой цели вроде можно обойтись без макроса, напр. паттерном "декоратор"
P1
В FAQ чикена про потоки написано следующее
Native threads are not supported for two reasons. One, the runtime system is not reentrant. Two, concurrency implemented properly would require mandatory locking of every object that could be potentially shared between two threads. The garbage-collection algorithm would then become much more complex and inefficient
В связи с этим возникает вопрос: А можно ли вообще полноценное gui приложение написать с таким ограничением?
Native threads are not supported for two reasons. One, the runtime system is not reentrant. Two, concurrency implemented properly would require mandatory locking of every object that could be potentially shared between two threads. The garbage-collection algorithm would then become much more complex and inefficient
В связи с этим возникает вопрос: А можно ли вообще полноценное gui приложение написать с таким ограничением?
вот как там конкретно в ципе, не скажу точно, т.к. с ним не работаю, но один поток ещё никогда не мешал организовать event-loop (как в том-же ES сделано)
AZ
сложно сходу понять, получился довольно запутаный код, но для такой цели вроде можно обойтись без макроса, напр. паттерном "декоратор"
(Про "вроде можно обойтись без макроса") Я примерно так и пытался. Работает не так как задумано, при определенных условиях сегфолты
P1
(Про "вроде можно обойтись без макроса") Я примерно так и пытался. Работает не так как задумано, при определенных условиях сегфолты
а, вижу, надо попробовать запустить завтра
PG
Почему бы не сделать BEAM-like интерпретатор/рантайм с отдельной кучей на каждый поток?
AZ
Почему бы не сделать BEAM-like интерпретатор/рантайм с отдельной кучей на каждый поток?
Ну в теории оно так и надо, просто не знаю смогу ли сделать
PG
То есть ты собираешь сделать свою реализацию схемы или допилить существующую?
AZ
То есть ты собираешь сделать свою реализацию схемы или допилить существующую?
Идея какая: создать отдельный поток pthread и просто инициализировать там новый контекст исполнения с помощью C API
https://wiki.call-cc.org/man/4/Embedding#chicken_initialize
https://wiki.call-cc.org/man/4/Embedding#chicken_initialize
AZ
Прокатит или нет, не знаю, но по идее должно
PG
Интересно
PG
Там же можно пересылать объекты между кучами?
AZ
Там же можно пересылать объекты между кучами?
Без понятия. Но в крайнем случае можно сериализовывать\десериализовывать и просто в виде строки передавать
no
После перехода на jit, скорость guile сильно подросла?
no
"Guile uses the GNU Lightning library to emit native code"