Comments 12
Наверное зря, но я не смог удержаться =/
Надеюсь, никто не добавит туда еще язык R
нельзя запустить код на D из кода на python, встроенного в код на D
Фундаментальная проблема. Без callback-ов жить не очень здорово и наличие этой проблемы говорит о том, что виртуальная машина не fully-resumable, что влечет за собой еще целый ряд сюрпризов.
Насчёт фундаментальности я говорил в плане исправления. Ошибка при запуске программы была вида 'already defined', и относилась к загрузке дин. библиотеки phobos. Но видимо я несколько ошибся насчёт простоты её исправления. Не совсем понял насчёт виртуальной машины. pyd не является самостоятельной виртуальной машиной, используется cpython, может я не совсем понял о чём Вы? И что означает термин full-resumable?
Есть стандартная проблема при вызове нативного кода из виртуальной машины: казалось бы, необходимо просто сохранить контекст выполнения, выполнить код и возобновить работу из контекста, но если вызвать из нативного кода интерпретируемый, с этим самым сохраненным контекстом возникнет нештатная ситуация. Еще одна стандартная проблема в подобной ситуации — сборка мусора. Во многих случаях обе проблемы решаемы, но это явно не 3 строчки кода.
Почему не три строчки? Я писал биндинги к Python в Vim и там есть следующие случаи:
Сборка мусора вызывала не больше проблем, чем прямое управление памятью в других участках кода, при том проблемы были только с собственными типами, определёнными в C.
- Вызов Python из C: + две строчки: взятие GIL и освобождение GIL.
- Вызов C из Python, если код на C не может вызвать Python и вообще работает быстро: ничего не нужно вообще, только структуры с описанием функций, чтобы Python знал, что можно вызвать.
- Вызов C из Python, если C код может вызвать Python (или работает медленно и нам бы хотелось разрешить Python работать в других потоках во время работы кода): + две строчки: макросы Py_BEGIN_ALLOW_THREADS и Py_END_ALLOW_THREADS. Там ещё вызываются прикольные функции «Python_Lock_Vim()» и парная Release, но они ничего не делают (и их можно было спрятать под свой макрос).
Сборка мусора вызывала не больше проблем, чем прямое управление памятью в других участках кода, при том проблемы были только с собственными типами, определёнными в C.
Самый шик — это написать интерпретатор Python на D в виде статического компилятора.
Интерпретатор в виде статического компилятора? Это как?
Или вы про JIT/AOT?
Или вы про JIT/AOT?
Это трансляция Python в D налету во время компиляции.
Трансляция python в D это кажется вот это.
Не совсем понимаю зачем это может быть нужно, имхо смысл python встраивать в D в том, что python динамичный, его не надо компилировать, его можно использовать как конфиг программы, изменять на лету и тд, то есть по настоящему скриптовой язык. А так получается ни рыба ни мясо.
Не совсем понимаю зачем это может быть нужно, имхо смысл python встраивать в D в том, что python динамичный, его не надо компилировать, его можно использовать как конфиг программы, изменять на лету и тд, то есть по настоящему скриптовой язык. А так получается ни рыба ни мясо.
UFO just landed and posted this here
Sign up to leave a comment.
Python и D