KDevPlatform ruby extension progress

[Richard Dale]

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.


> > 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:

Index: project/interfaces/iprojectbuilder.h
===================================================================
--- project/interfaces/iprojectbuilder.h        (revision 816727)
+++ project/interfaces/iprojectbuilder.h        (working copy)
@@ -84,27 +84,27 @@
     /**
      * Emitted when the build for the given item was finished
      */
-    void built(ProjectBaseItem *dom);
+    virtual void built(ProjectBaseItem *dom) = 0;
     /**
      * Emitted when the install for the given item was finished
      */
-    void installed(ProjectBaseItem*);
+    virtual void installed(ProjectBaseItem*) = 0;
     /**
      * Emitted when the clean for the given item was finished
      */
-    void cleaned(ProjectBaseItem*);
+    virtual void cleaned(ProjectBaseItem*) = 0;
     /**
      * Emitted when any of the scheduled actions for the given item was
failed
      */
-    void failed(ProjectBaseItem *dom);
+    virtual void failed(ProjectBaseItem *dom) = 0;
     /**
      * Emitted when the configure for the given item was finished
      */
-    void configured(IProject*);
+    virtual void configured(IProject*) = 0;
     /**
      * Emitted when the pruning for the given item was finished
      */
-    void pruned(IProject*);
+    virtual void pruned(IProject*) = 0;
 };

 }

Is there a reason why the signals aren't abstract? It is straightforward to
special case these methods, and so it isn't a great problem.

-- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20080608/3d56953c/attachment.html>