fxruby users - Sep 2005 - Re: FXRuby issues

On Sep 3, 2005, at 3:58 AM, Gonzalo Garramuno wrote:
> Sorry to bother you personally, but after working with FXRuby for the 
> first time on a relatively medium-sized project, I collected a list of 
> things that seem to be broken in fxruby (or fox), and I thought it 
> would be good for you guys to be aware of.
> Some of these things I consider them somewhat serious in term of 
> recommending fxruby for larger projects, which is unfortunate, cause I 
> overally really liked how the API is designed.
> ?
> Unless specified, problems seem to show in both 1.2 and 1.4, under 
> Windows, at least.? The main things I run into problems were:
> ?
> *?Segfaults.
> FXRuby segfaults quite a lot.? This, for once, happens when things are 
> not created, which is understandable, but bad anyway, compared to 
> other toolkits like FLTK, TK, etc. where segfaults are simply not 
> possible (other than the library is buggy).
When an FXRuby application segfaults, it''s almost always the fault of 
the FXRuby bindings themselves and not the underlying FOX library.
> But more so, I also found segfaults with:
> ??? - crashes when creating large canvases/images.? These were pretty 
> weird.? I basically could not get FxRuby to have a 4K or 
> 8K?canvas+image buffer.? I am not sure how this could be as a 128Mb + 
> 2GB swap should be enough for handling this with no problem.? Worse, 
> fxruby would just segfault upon creation.? No "out of memory"
message
> or anything.? This is overall pretty bad.
> ??? - segfaults sometimes when an actual ruby exception was raised 
> (runtime error, syntax error, etc).? What was bad about this is that 
> it would
> ??????often not allow ruby to actually flush and print the actual 
> error that caused the crash, leaving you somewhat in the dark as to 
> what
> ????? happened (Fox issue???issue in my code?)? Again, this was pretty 
> bad.
> ??? - 1.4 seems to have some issues with the garbage collector.? 
> GC.start will often segfault it.
It would be great if you could submit a bug report to the tracker at 
RubyForge 
(http://rubyforge.org/tracker/?atid=1223&group_id=300&func=browse) that 
describes in detail how to reproduce any of these problems. A short 
example program that does so is even better.
> *?The whole versioning thing.? I mentioned this already.?
Yes, we disagree about this. There are usually non-trivial API changes 
between major releases of FOX. This was true going from FOX 1.0 to 1.2, 
and again from 1.2 to 1.4. I''m glad that your application required few,
if any, changes to "port" it from FXRuby 1.2 to 1.4, but
that''s the
exception and not the rule, as I think long-time users will attest.
> * Windows focus bugs
This sounds like a bug (or feature) of the FOX library itself. You 
might try reporting it to the foxgui-users mailing list to see if 
anyone has any suggestions.
> * Custom mouse icons will not allow hotspot to be changed.? Setting 
> hotspot to anything positive in the constructor, crashes fxruby.? 
> Using setHotX/Y on 1.4 does nothing.? At least on windows.
If the FOX library doesn''t allow you to change the hotspot for custom 
icons, I can''t do anything about that in the FXRuby layer either, but 
I''ll check into it. The code shouldn''t crash when setting the
hotspot,
and that should be easy enough for me to test.
> * The way the DC classes are designed are great but:
> ??? - FXDCPrint is just way too buggy and incomplete.? It probably 
> should be removed from the release (or a word of warning in the docs 
> should be present)
> ??? - FXDC is in serious need of supporting:
> ??? ??? * bezier/bspline drawing
> ??? ??? * hit testing
> ??? ??? * FXDCWindow''s with double buffering (sans opengl)
> ????? Three things that are relatively common in other toolkits (Tk, 
> FLTK, etc).
These are again shortcomings of FOX itself. You can report them to the 
foxgui-users list if you like.
> ????* The new 1.4 tooltip callback is buggy.? On startup of the 
> program, it will often not get called until the user clicks on 
> something.? And other times, the tooltip will popup for no reason, 
> using the default popup text.
OK, will check into this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5595 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/fxruby-users/attachments/20050903/7c82fc3a/attachment.bin

On Saturday 03 September 2005 10:15 am, Lyle Johnson
wrote:
> On Sep 3, 2005, at 3:58 AM, Gonzalo Garramuno wrote:
> > Sorry to bother you personally, but after working with FXRuby for the
> > first time on a relatively medium-sized project, I collected a list of
> > things that seem to be broken in fxruby (or fox), and I thought it
> > would be good for you guys to be aware of.
> > Some of these things I consider them somewhat serious in term of
> > recommending fxruby for larger projects, which is unfortunate, cause I
> > overally really liked how the API is designed.
> > ?
> > Unless specified, problems seem to show in both 1.2 and 1.4, under
> > Windows, at least.? The main things I run into problems were:
> > ?
> > *?Segfaults.
> > FXRuby segfaults quite a lot.? This, for once, happens when things are
> > not created, which is understandable, but bad anyway, compared to
> > other toolkits like FLTK, TK, etc. where segfaults are simply not
> > possible (other than the library is buggy).
>
> When an FXRuby application segfaults, it''s almost always the fault
of
> the FXRuby bindings themselves and not the underlying FOX library.
>
> > But more so, I also found segfaults with:
> > ??? - crashes when creating large canvases/images.? These were pretty
> > weird.? I basically could not get FxRuby to have a 4K or
> > 8K?canvas+image buffer.?
Well there are GDI limits ofcourse.... FOX will throw a exception if limits 
are reached....

	Sander

On Sep 3, 2005, at 8:39 AM, Sander Jansen wrote:
> Well there are GDI limits ofcourse.... FOX will throw a exception if 
> limits
> are reached...
True, but I doubt that''s the case for Gonzalo''s application,
especially
if the buffer size is only 4 or 8k in size.

Yes, it isn''t that.  What''s more, I''ve been trying to
debug a still present
crashing bug that will crash the application after some time of use (an hour
or so), and I now have a definitive clue as to what''s causing it.

In my code, I basically have code that does:

 @image.release
 @image.destroy
  GC.start
 @image = FXBMPImage.new(@window.getApp, nil, IMAGE_SHMI|IMAGE_SHMP,
    width, height)
 @image.create

whenever the user zooms in/out on the canvas (or the canvas is resized as a
result of the map growing).  I have verified that width, height and @window
are valid thru printing statements, yet I have noticed that sometimes the
FXBMPImage.new() function does not return.
Instead it seems to pop the ruby stack, returning from the current function,
leaving @image unitialized and uncreated (ie. @image.create and subsequent
code is never reached).
My guess is that there''s probably some sort of exception being raised
in the
FXBMPImage constructor of which ruby is never made aware of.
This eventually leads to a crash later on in my code, whenever a DC context
wants to be inited with that image, as it remains unitialized.

On that subject, is there any way I can check if an element is created.
Something like @image.created?