On Wed, Sep 10, 2008 at 11:37 AM, Koen Deforche <[EMAIL PROTECTED]> wrote:
> Hey Richard, > > 2008/8/31 Richard Dale <[EMAIL PROTECTED]>: > > I spent the last week working on the WtRuby bindings and have made good > > progress: > > Great to hear! > > > I need to make some changes to the Wt sources to get the bindings code > > generation working (see attached 'wt_ruby.patch'): > > > > * In Wt/Ext/TextEdit the resize() virtual method has a different > signature > > to the one it is overriding and I got 'hidden virtual method' warnings > and > > code gen problems. > > > > I changed: > > void TextEdit::resize(const WLength& width, const WLength& height) > > > > To: > > void TextEdit::resize(WLength width, WLength height) > > > > * There was a similar problem with the layout() virtual method changing > its > > signature from const to non-const. I could only get the code gen to work > by > > making it always non-const. > > These problems have recently been solved in CVS. Some other compilers > were complaining (or warning) about exactly the same problems too. The > fixes are not exactly like you suggested (we now pass WLength always > by reference). OK, I've checked out the CVS version of Wt, but haven't tried to build it yet. > > > > * Wt/Ext/Widget has a private pure virtual method createJS(). which > caused > > code gen problems, and I could only get it to work by making it protected > > I'm not sure I understand why, but I have nothing really against it... I've got that working fine now with the private version, and skip the other createJS() methods altogether as I don't think they are part of the public api, although two of them are protected. > > > > * Forward class declarations and extra includes needed to be added to > some > > headers, to make them compile in the generated code. > > Very okay with that! > > > When I tried the standard multi-threaded wthttp library with Ruby, it > didn't > > work and Ruby threw stack overflow exceptions, and I needed to build a > > single threaded version. I couldn't get the cmake option > > '-DMULTI_THREADED=off' to work, and so I had to hack the cmake link.txt > > files to remove the compile option '-DTHREADED'. I also needed to make > some > > small changes to the WServer.C file to get it to work (please see > > wt_http_threaded.patch). > > These were also very recently fixed in CVS. > > Is multi threading supposed to work in Ruby in the end? I am asking > since to my surprise, this turned out to be a big problem in Python > (one which is not solved yet). And, I consider it almost a must-have > feature. No it doesn't work in Ruby as Ruby threads aren't real threads, but are implemented using setjmp()s and longjmp()s. So we would have to use the no threading version of wthttp for testing, and fastcgi for production. However, I think that means that a new process would be needed for every concurrent connection and I don't know how scaleable that is. I've been wondering whether it would be possible to have a single pthread holding all the ruby threads, where each Ruby thread has another 'worker pthread' that it makes any C++ calls too. Any callbacks from one of these worker threads would need to be directed back to the correct ruby thread (I'm not sure how easy that is as the Ruby C api doesn't really have any support for Ruby threads as far as I can see). For small intranet based applications (eg up to say 32 users) I think one process per user in the web server is ok, and it might be best to concentrate on getting the bindings 100% solid and complete before starting on trying to make them scale better. > > > So that's it so far - I'm quite excited about how well it seems to work, > and > > have just downloaded the Ext 2.0 java script widgets to try out which > will > > be very interesting. Although the project isn't quite ready to release, I > > can tar up the sources and mail them to anyone who is interested in > trying > > it out. > > I am willing to give it a try as soon as you think it is easily usable > by a non-rubyist? Yes, you should be able to follow the code quite easily - I've attached the Ruby version of the Ext Kitchen example, which is fully working now. I've converted about 2/3 of the examples to ruby including the chart and extkitchen ones. At the moment I have the two smoke library and two ruby extensions built as part of the kde svn trunk kdebindings module. And so if you can build the ruby bindings from the kde svn it should be easy to add the Wt ones. It would take more work to make the Wt bindings stand alone for a first release, and I'll try and do that next week probably when I've done a bit more work on slots/signals mainly, and converting more examples like hangman with database support via Rails ActiveRecord. I've sent several messages to this list, which haven't arrived and so if this one doesn't make it I'll forward it to you personal mail address.. -- Richard
extkitchenapplication.rb
Description: application/ruby
csvutil.rb
Description: application/ruby
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
