KDevPlatform ruby extension progress

[Andreas Pakulat]

On 08.06.08 20:27:00, Richard Dale wrote:
> On Sat, Jun 7, 2008 at 9:05 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> > On 07.06.08 18:13:36, Richard Dale wrote:
> > > I've checked in a kdevplatform Smoke library and a ruby extension that
> > uses
> > > it, into kdebindings/smoke/kdevplatform and kdebindings/ruby/kdevplatform
> > > respectively. There are over 125 KDevelop:: and Sublime:: classes
> > wrapped,
> > > although I still need to add the list marshallers for the Ruby extension
> > > (that shouldn't take long).
> > >
> > > The following classes gave problems with either the code generation or
> > > linking and weren't wrapped:
> > >
> > > KDevelop::BackgroundParser
> >
> > That might be needed for language supprt
> >
> > > KDevelop::ContextOwner
> >
> > That one too.
> >
> > > KDevelop::Definition
> >
> > That doesn't exist anymore.
> >
> > > KDevelop::IBuildSystemManager
> >
> > only for buildsystem stuff
> >
> > > KDevelop::IDocumentController
> >
> > That one is probably needed too, for example for opening a file...
> >
> > > KDevelop::IPluginController
> >
> > Not for a ruby language plugin.
> >
> > > KDevelop::IProject
> > > KDevelop::IProjectBuilder
> > > KDevelop::IProjectFileManager
> >
> > Probably also not needed.
> >
> > > KDevelop::IQuickOpen
> >
> > That one might be needed, but I don't know the quick-open stuff too
> > well.
> >
> > > KDevelop::IRunProvider
> > > KDevelop::IStatus
> >
> > I don't think these are needed.
> >
> > > KDevelop::DUContext::SearchItem
> > > KDevelop::DUChainObserver
> >
> > I'm not sure about the latter here, might be needed for some stuff.
> >
> > > KDevelop::QuickOpenFileSetInterface
> > >
> > > I hope that none of these will be a showstopper WRT developing a Ruby
> > > language plugin in Ruby. I wonder if the use of threading with
> > ThreadWeaver
> > > is going to be a problem with Ruby as it isn't threadsafe. Perhaps as
> > long
> > > as Ruby code is only ever running in one thread it will be ok.
> >
> > Its possible to limit the parser to one thread, but that thread still is
> > not the GUI thread and part of the code in a language plugin will run in
> > the GUI thread (while another part runs in the parser thread). Then
> > again I'm not sure what "not threadsafe" means in this context as the
> > ruby plugin would use C++ code that is threadsafe for locking and such
> > things.
> 
> 'Not threadsafe' means Ruby running in two threads at once. The Ruby parser
> will be written in C++ and so I assume it will run in the background ok.

Well, last I talked with Alexander about this he wanted to stop the c++
parser for ruby and do it all in ruby because its much easier :)

> > > The vcs headers gave a lot of compile problems and so I've left them out
> > for
> > > now.
> >
> The problems with the interface classes was that they don't just contain
> pure virtual methods as you would expect in an interface class, as the
> signals are not virtual. So the bindings code generator assumes that there
> are definitions implemented, and then the generated code fails to link
> against the non-existent method definition code. For instance, if I patch
> the iprojectbuilder.h file like this the code generates fine:

Aah, ok. I'll see what happens if I make the signals pure virtuals (it
should work). The "signals" keyword on those classes is ignored anyway
so they're just functions and indeed should either be pure virtual or
implemented...

Andreas

-- 
You learn to write as if to someone else because NEXT YEAR YOU WILL BE
"SOMEONE ELSE."