- Jul 07, 2015
-
-
Lars Kanis authored
-
- Jul 06, 2015
-
-
Lars Kanis authored
This should ensure, that the event is definitely cleared. These functions should be thread safe.
-
Lars Kanis authored
-
Lars Kanis authored
Switch off polling-based (addChore) processing of threads Add event-based interruption of GVL-released functions.
-
- Jun 25, 2015
-
-
Lars Kanis authored
-
Lars Kanis authored
This works for sockets only for now.
-
- Jun 24, 2015
-
-
Lars Kanis authored
-
Lars Kanis authored
-
Lars Kanis authored
-
- Jun 14, 2015
-
-
Lars Kanis authored
-
- Jun 13, 2015
-
-
Lars Kanis authored
-
Lars Kanis authored
This is the only function that is currently required to acquire the GVL. Other FXRbCall functions could be wrapped equally.
-
Lars Kanis authored
This is just enough for loadPixel/savePixel, but if other methods release the GVL, potentially all other callback functions could be called. These are now yet wrapped by gvl-aware wrappers.
-
- Jun 12, 2015
-
-
Lars Kanis authored
-
Lars Kanis authored
-
- Jun 08, 2015
-
-
Lars Kanis authored
This also fixes some build system checks, that should be for the target system.
-
- Feb 20, 2015
-
-
Lars Kanis authored
-
Lars Kanis authored
without check.
-
- Feb 19, 2015
-
-
Lars Kanis authored
-
Lars Kanis authored
This solves crashes of kind: [BUG] rb_gc_mark(): 0x00000003f54af8 is T_ZOMBIE All parameters to Ruby event blocks or overloaded methods are converted to proper Ruby classes or wrapped by appropriate wrapper classes for borrowed objects. The wrapper classes are registered, to keep the connection between C-pointer (the borrowed object) and the wrapping Ruby object. This connection is canceled either when the borrowed object is destroyed or the Ruby wrapper is free'd. If neither of them happens, the wrapper object is re-used for the next call. This worked good with Ruby-1.8, which has one big mark and sweep run. Ruby-2.2 introduced incremental GC and has several mark and sweep runs, so that marks and sweeps are quite independent. Therefor we re-used objects, that are already maked for sweeping (so called T_ZOMBIE). This patch releases the connection between borrowed object and it's wrapper object after each call into Ruby code. Therefore the wrapper object isn't re-used, but a new one is created for each param to each call. The wrapper objects are later free'd by the GC. This patch could have a negative performance impact.
-
- Feb 18, 2015
-
-
Lars Kanis authored
-
Lars Kanis authored
-
- Feb 17, 2015
-
-
Lars Kanis authored
Static linking all dependent libraries into each ruby version (from 1.8 to 2.2) would blow up the gem to >20MB.
-
- Feb 14, 2015
-
-
Lars Kanis authored
-
Lars Kanis authored
-
- Mar 17, 2014
-
-
Lars Kanis authored
This way it also works for derived classes like FXJPGImage.
-
- Mar 16, 2014
-
-
Lars Kanis authored
Allow retrival of parts of the pixel data.
-
- Mar 13, 2014
-
-
Lars Kanis authored
../../../../ext/fox16_c/FXRbApp.cpp: In static member function ‘static FXRbApp* FXRbApp::constructAndInit(const FXchar*, const FXchar*)’: ../../../../ext/fox16_c/FXRbApp.cpp:58:28: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings] static char* argv[]={"",0}; ^
-
Lars Kanis authored
-
- Sep 28, 2013
-
-
Lars Kanis authored
This fixes issue #10. Stacktrace was: ==4561== Invalid read of size 8 ==4561== at 0x4F726FF: st_lookup (st.c:414) ==4561== by 0x4FCEAD6: rb_method_entry_get_without_cache (vm_method.c:182) ==4561== by 0x4FD94E5: rb_funcall (vm_eval.c:315) ==4561== by 0x810DAF2: FXRbCallVoidMethod(FX::FXObject*, unsigned long) (in /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/fxruby-1.6.28/lib/fox16_c.so) ==4561== by 0x81AC98E: FXRbTreeList::recalc() (in /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/fxruby-1.6.28/lib/fox16_c.so) ==4561== by 0x8FC78DC: FX::FXTreeList::removeItems(FX::FXTreeItem*, FX::FXTreeItem*, unsigned char) (FXTreeList.cpp:2340) ==4561== by 0x8FC7916: FX::FXTreeList::removeItem(FX::FXTreeItem*, unsigned char) (FXTreeList.cpp:2347) ==4561== by 0x829ED0F: FXRbTreeItem::freefunc(FX::FXTreeItem*) (in /home/lars/.rvm/gems/ruby-2.0.0-p247/gems/fxruby-1.6.28/lib/fox16_c.so) ==4561== by 0x4EBA505: finalize_list (gc.c:1415) ==4561== by 0x4EC15A3: rb_gc_call_finalizer_at_exit (gc.c:1552) ==4561== by 0x4EA8064: ruby_cleanup (eval.c:127) ==4561== by 0x4EA8292: ruby_run_node (eval.c:307) ==4561== Address 0x74fb894853ff8550 is not stack'd, malloc'd or (recently) free'd ==4561== segfault_on_close.rb: [BUG] Segmentation fault
-
- Jun 28, 2013
-
-
Lars Kanis authored
So we need to use it properly too. See bug https://bugs.ruby-lang.org/issues/6504#change-38019
-
- Mar 31, 2013
-
-
Lars Kanis authored
Update cross compilation tasks to build x64 and x86 targets.
-
- Feb 26, 2013
-
-
Lars Kanis authored
-
Lars Kanis authored
-
- Feb 15, 2013
-
-
Lars Kanis authored
-
- Jan 03, 2013
-
-
Lars Kanis authored
Before commit af543822 loading order of fox16.so and fox16.rb was irrelevant. But now fox16.rb must be called, in order to load ruby files to the C++ extension. Renaming the C++ extension ensures, that fox16.rb is called first.
-
- Jun 16, 2012
-
-
Lars Kanis authored
The internal object allocated when calling FXSplashWindow.new was FXSplashWindow instead of FXRbSplashWindow, so that no FXRbUnregisterRubyObj() was called. Therefore the object was double free'd. Stacktrace was: ==11529== Invalid read of size 8 ==11529== at 0x9265BBC: FX::FXObject::getClassName() const (FXObject.cpp:280) ==11529== by 0x862EE55: FXRbObject::freefunc(FX::FXObject*) (markfuncs.cpp:77) ==11529== by 0x4EA6254: finalize_list (gc.c:2944) ==11529== by 0x4EAAFC2: rb_gc_call_finalizer_at_exit (gc.c:3075) ==11529== by 0x4E9773B: ruby_cleanup (eval.c:101) ==11529== by 0x4E979C4: ruby_run_node (eval.c:244) ==11529== by 0x4007FA: main (main.c:38) ==11529== Address 0x75e24c0 is 0 bytes inside a block of size 248 free'd ==11529== at 0x4C2A4BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11529== by 0x92B98AD: FX::FXSplashWindow::~FXSplashWindow() (FXSplashWindow.cpp:219) ==11529== by 0x917C990: FX::FXComposite::~FXComposite() (FXComposite.cpp:304) ==11529== by 0x929A5EF: FX::FXRootWindow::~FXRootWindow() (FXRootWindow.cpp:209) ==11529== by 0x929A621: FX::FXRootWindow::~FXRootWindow() (FXRootWindow.cpp:211) ==11529== by 0x9156DB9: FX::FXApp::~FXApp() (FXApp.cpp:4994) ==11529== by 0x84912F3: FXRbApp::~FXRbApp() (FXRbApp.cpp:118) ==11529== by 0x8491347: FXRbApp::~FXRbApp() (FXRbApp.cpp:127) ==11529== by 0x862EF8E: FXRbObject::freefunc(FX::FXObject*) (markfuncs.cpp:92) ==11529== by 0x4EA6254: finalize_list (gc.c:2944) ==11529== by 0x4EAAFC2: rb_gc_call_finalizer_at_exit (gc.c:3075) ==11529== by 0x4E9773B: ruby_cleanup (eval.c:101)
-
- Jun 15, 2012
-
-
Lars Kanis authored
-
Lars Kanis authored
-
- Jun 01, 2012
-
-
Lars Kanis authored
Don't include sys/time.h for cross compilation, this avoids the fix for incompatible types of gettimeofday()
-