diff options
Diffstat (limited to 'community/gsoc/project_ideas/language_bindings.mdwn')
| -rw-r--r-- | community/gsoc/project_ideas/language_bindings.mdwn | 42 |
1 files changed, 40 insertions, 2 deletions
diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn index 61a3fa01..344b741c 100644 --- a/community/gsoc/project_ideas/language_bindings.mdwn +++ b/community/gsoc/project_ideas/language_bindings.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013, 2014 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -61,3 +61,41 @@ bindings](http://www.nongnu.org/hurdextras/#pith), which might serve as a reference if you want to work on Perl. Possible mentors: Anatoly A. Kazantsev (anatoly) for Python + + +# Discussion + +## [[user/jkoenig/Java]] + +## IRC, freenode, #hurd, 2013-12-19 + + <antrik_> teythoon_: I don't think wrapping libtrivfs etc. for guile + bindings is really desirable... for the lisp bindings, we agreed that + it's better to hook in at a lower level, and build more lispish + abstractions + <antrik> trivfs is a C framework; it probably doesn't map very well to + other languages -- especially non-imperative ones... + <antrik> (it is arguable whether trivfs is really a good abstraction even + for C... but that's another discussion :-) ) + <antrik> ArneBab: same for Python bindings. when I suggested ignoring + libtrivfs etc., working around the pthread problem was just a side effect + -- the real goal has always been nicer abstraction + <anatoly> antrik: agree with you + <anatoly> antrik: about nicer abstractions + <teythoon_> antrik: I agree too, but wrapping libtrivfs is much easier + <teythoon_> otherwise, one needs to reimplement lots of stuff to get some + basic functionality + <teythoon_> like a mig that emits your language + <braunr> i agree with antrik too + <braunr> yes, the best would be mig handling multiple languages + +[[!taglink open_issue_mig]]. + + <antrik> teythoon_: not exactly. for dynamic languages, code generation is + silly. just handle the marshalling on the fly. that's what the Lisp + bindings are doing (AFAIK) + <teythoon> antrik: ok, but you'd still need to parse the rpc definitions, + no? + <antrik> teythoon: yeah, you still need to parse the .defs -- unless we add + reflection to RPC interfaces... + <antrik> err, I mean introspection |