From pijnacker at dse.nl Wed Apr 4 04:34:48 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Wed, 4 Apr 2007 10:34:48 +0200 Subject: [ruby-opengl-devel] Windows support In-Reply-To: <200703301648.31298.jan.dvorak@kraxnet.cz> References: <20070329100148.GC31850@best.ms.philips.com> <200703301207.13034.jan.dvorak@kraxnet.cz> <20070330113847.GM31850@best.ms.philips.com> <200703301648.31298.jan.dvorak@kraxnet.cz> Message-ID: <20070404083448.GB11974@best.ms.philips.com> > On Friday 30 March 2007 13:38, you wrote: > > The reason I included glext.h was a missing definition of 'GLsizeiptr' > > for glBufferData. Maybe that should be added somewhere then? > I knew i missed something :) Thanks for pointing this out. Yes, some new > datatypes were introduced in new GL versions and also extensions. I'm > attaching patch that should add them to top of gl-enums.h. Let me know if > this works for you, if yes i'll add it to SVN. I'm sorry that i can't test > this properly as i currently don't have working windows installation. It seems to work fine, no more glext.h is needed. > > I think that it would be hard to make any assumptions there. > > Therefore it might at least be sensible to document that it is expected > > somewhere and that e.g. using INCLUDE and LIB environment variables they > > should be able to be resolved. > Yes. > > > Maybe glut.h could be shipped with the one-click-installer, just as the > > .lib file seems to be. To me it does not make sense that the .lib is > > there without having the .h too. > That would make sense, yes. I'll post a message to the one-click-installer user list about this. Regards, Ronald. From pijnacker at dse.nl Wed Apr 4 06:11:19 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Wed, 4 Apr 2007 12:11:19 +0200 Subject: [ruby-opengl-devel] glGetObjectParameter Message-ID: <20070404101119.GC11974@best.ms.philips.com> Hi all, I cannot seem to find glGetObjectPararmeter* in the wrapper. Is this function left out for any particular reason? Groeten, Ronald. From pijnacker at dse.nl Wed Apr 4 07:04:37 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Wed, 4 Apr 2007 13:04:37 +0200 Subject: [ruby-opengl-devel] glGetObjectParameter In-Reply-To: <20070404101119.GC11974@best.ms.philips.com> References: <20070404101119.GC11974@best.ms.philips.com> Message-ID: <20070404110437.GD11974@best.ms.philips.com> > Hi all, > > I cannot seem to find glGetObjectPararmeter* in the wrapper. > Is this function left out for any particular reason? Also, it seems that glCreateShaderObject is named glCreateShader. Why? Ronald. From pijnacker at dse.nl Wed Apr 4 07:24:29 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Wed, 4 Apr 2007 13:24:29 +0200 Subject: [ruby-opengl-devel] glGetObjectParameter In-Reply-To: <20070404110437.GD11974@best.ms.philips.com> References: <20070404101119.GC11974@best.ms.philips.com> <20070404110437.GD11974@best.ms.philips.com> Message-ID: <20070404112428.GE11974@best.ms.philips.com> > > Hi all, > > > > I cannot seem to find glGetObjectPararmeter* in the wrapper. > > Is this function left out for any particular reason? > > Also, it seems that glCreateShaderObject is named glCreateShader. Why? Hm... apparently the object part was dropped along with the ARB part. Sorry... Probably getGetObjectParameter* is called something different now too. Ronald. From pijnacker at dse.nl Wed Apr 4 16:58:51 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Wed, 4 Apr 2007 22:58:51 +0200 Subject: [ruby-opengl-devel] rake gem Message-ID: <20070404205851.GA13481@localhost> Hi all, I was trying to install the new version of ruby-opengl from svn in Ubuntu 6 at home, using 'rake gem'. However it does not seem to build at all, and the gem that was created complains about the gems version (which is 0.9.2 but should be > 0.9.1 ???). Is the 'rake gem' target not correct currently? If not, I could have a look at that after fixing the windows build. Ronald. From jan.dvorak at kraxnet.cz Wed Apr 4 20:17:07 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Thu, 5 Apr 2007 02:17:07 +0200 Subject: [ruby-opengl-devel] glGetObjectParameter In-Reply-To: <20070404112428.GE11974@best.ms.philips.com> References: <20070404101119.GC11974@best.ms.philips.com> <20070404110437.GD11974@best.ms.philips.com> <20070404112428.GE11974@best.ms.philips.com> Message-ID: <200704050217.07262.jan.dvorak@kraxnet.cz> On Wednesday 04 April 2007 13:24, Ronald Pijnacker wrote: > Hm... apparently the object part was dropped along with the ARB part. > Sorry... Probably getGetObjectParameter* is called something different > now too. Yes, when the shading was promoted to core feature in 2.0, the syntax changed. glGetObjectParameterARB functionality is accessible through glGetShader/glGetProgram Jan From pijnacker at dse.nl Thu Apr 5 01:43:22 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Thu, 5 Apr 2007 07:43:22 +0200 Subject: [ruby-opengl-devel] glGetObjectParameter In-Reply-To: <200704050217.07262.jan.dvorak@kraxnet.cz> References: <20070404101119.GC11974@best.ms.philips.com> <20070404110437.GD11974@best.ms.philips.com> <20070404112428.GE11974@best.ms.philips.com> <200704050217.07262.jan.dvorak@kraxnet.cz> Message-ID: <20070405054322.GG11974@best.ms.philips.com> > On Wednesday 04 April 2007 13:24, Ronald Pijnacker wrote: > > Hm... apparently the object part was dropped along with the ARB part. > > Sorry... Probably getGetObjectParameter* is called something different > > now too. > Yes, when the shading was promoted to core feature in 2.0, the syntax changed. > glGetObjectParameterARB functionality is accessible through > glGetShader/glGetProgram > > Jan Thanks Jan. Ronald. From pijnacker at dse.nl Thu Apr 5 07:05:20 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Thu, 5 Apr 2007 13:05:20 +0200 Subject: [ruby-opengl-devel] Support for building on Windows Message-ID: <20070405110520.GA5092@localhost> Hi all, I'd better send this to the right mailing list too. Ronald. -------------- next part -------------- An embedded message was scrubbed... From: Ronald Pijnacker Subject: Re: [Mkrf-users] Support for building on Windows Date: Thu, 5 Apr 2007 12:12:08 +0200 Size: 5499 Url: http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070405/eb928e15/attachment.mht From pijnacker at dse.nl Thu Apr 5 07:35:51 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Thu, 5 Apr 2007 13:35:51 +0200 Subject: [ruby-opengl-devel] Patch for building on windows Message-ID: <20070405113551.GK11974@best.ms.philips.com> Hi all, I've attached the patch for making ruby-opengl build on windows. This includes the patch Jan sent out last week that provides the extra typedefs. For now, I've chosen to export the Init_* functions using the dllexport keyword, that keeps me from having to support -def: in mkrf. Please have a look and let me know what you think. Or better yet... commit in svn :-) The patch requires a patched version of mkrf, which I send to the mkrf mailing list. Groeten, Ronald. -------------- next part -------------- Index: ext/gl/gl.c =================================================================== --- ext/gl/gl.c (revision 171) +++ ext/gl/gl.c (working copy) @@ -25,6 +25,12 @@ #include "../common/rbogl.h" #include "../common/gl-enums.h" +#ifdef WIN32 +#define DLLEXPORT __declspec(dllexport) +#else +#define DLLEXPORT +#endif + static VALUE module; void gl_init_enums(VALUE); @@ -49,7 +55,7 @@ return Qtrue; } -void Init_gl() +DLLEXPORT void Init_gl() { module = rb_define_module("Gl"); gl_init_enums(module); Index: ext/gl/mkrf_conf.rb =================================================================== --- ext/gl/mkrf_conf.rb (revision 171) +++ ext/gl/mkrf_conf.rb (working copy) @@ -15,12 +15,16 @@ require 'rubygems' require 'mkrf' +require 'rbconfig' Mkrf::Generator.new( 'gl' ) do |g| - g.objects << '../common/rbogl.o' + g.objects << "../common/rbogl.#{Config::CONFIG['OBJEXT']}" case RUBY_PLATFORM when /darwin/ g.ldshared << ' -framework OpenGL' + when /mswin32/ + g.cflags << ' -DWIN32' + g.include_library( 'opengl32.lib', 'glVertex3d') else g.include_library( 'GL', 'glVertex3d') end Index: ext/glu/mkrf_conf.rb =================================================================== --- ext/glu/mkrf_conf.rb (revision 171) +++ ext/glu/mkrf_conf.rb (working copy) @@ -17,10 +17,14 @@ require 'mkrf' Mkrf::Generator.new( 'glu' ) do |g| - g.objects << '../common/rbogl.o' + g.objects << "../common/rbogl.#{Config::CONFIG['OBJEXT']}" case RUBY_PLATFORM when /darwin/ g.ldshared << ' -framework OpenGL' + when /mswin32/ + g.cflags << ' -DWIN32' + g.include_library( 'opengl32.lib', 'glVertex3d') + g.include_library( 'glu32.lib', 'gluLookAt') else g.include_library( 'GLU', 'gluLookAt' ) g.include_library( 'GL', 'glVertex3d') Index: ext/glu/glu.c =================================================================== --- ext/glu/glu.c (revision 171) +++ ext/glu/glu.c (working copy) @@ -33,8 +33,10 @@ #include "../common/rbogl.h" #ifdef WIN32 +#define DLLEXPORT __declspec(dllexport) typedef void (CALLBACK*(VOIDFUNC))(); #else +#define DLLEXPORT typedef void (*VOIDFUNC)(); #endif @@ -1448,8 +1450,7 @@ #define GLU_ERROR 100103 #endif - -void Init_glu() +DLLEXPORT void Init_glu() { callId = rb_intern("call"); refId = rb_intern("[]"); Index: ext/common/Rakefile =================================================================== --- ext/common/Rakefile (revision 171) +++ ext/common/Rakefile (working copy) @@ -20,20 +20,24 @@ INCLUDES = "-I#{Config::CONFIG['archdir']}" CFLAGS = "#{Config::CONFIG['CFLAGS']}" +CC = "#{Config::CONFIG['CC']}" +O = "#{Config::CONFIG['OBJEXT']}" case RUBY_PLATFORM when /darwin/ INCLUDES << ' -F/System/Library/Frameworks' +when /mswin32/ + CFLAGS << ' -DWIN32' end -CLEAN.include( '*.o' ) +CLEAN.include( '*.#{O}' ) SRC = FileList[ '*.c' ] -OBJ = SRC.ext( 'o' ) +OBJ = SRC.ext( O ) task :default => OBJ file 'rbogl.c' => [ 'rbogl.h' ] -rule '.o' => '.c' do |t| - sh "cc -c #{CFLAGS} #{INCLUDES} -o #{t.name} #{t.source}" +rule ".#{O}" => '.c' do |t| + sh "#{CC} -c #{CFLAGS} #{INCLUDES} #{t.source}" end Index: ext/common/rbogl.c =================================================================== --- ext/common/rbogl.c (revision 171) +++ ext/common/rbogl.c (working copy) @@ -293,13 +293,3 @@ return func_ptr; } - -/* -------------------------------------------------------------------- */ -void Init_gl(void); - -void Init_opengl() -{ - Init_gl(); /* is this needed ? */ - /* RxINC: InitializeGLU(); */ -} - Index: ext/common/gl-enums.h =================================================================== --- ext/common/gl-enums.h (revision 171) +++ ext/common/gl-enums.h (working copy) @@ -1,4 +1,42 @@ -/* This file was genereated on Sun Feb 11 01:24:24 +0100 2007 */ +/* GL types - define if system GLheaders are not recent */ + +/* GL base */ +#ifndef GL_VERSION_1_5 +typedef ptrdiff_t GLintptr; +typedef ptrdiff_t GLsizeiptr; +#endif + +#ifndef GL_VERSION_2_0 +typedef char GLchar; +#endif + +/* new GL types introduced by ARB extensions */ +#ifndef GL_ARB_half_float_pixel +typedef unsigned short GLhalfARB; +#endif + +#ifndef GL_ARB_shader_objects +typedef char GLcharARB; +typedef unsigned int GLhandleARB; +#endif + +#ifndef GL_ARB_vertex_buffer_object +typedef ptrdiff_t GLintptrARB; +typedef ptrdiff_t GLsizeiptrARB; +#endif + +/* new GL types introduced by other extensions */ +#ifndef GL_NV_half_float +typedef unsigned short GLhalfNV; +#endif + +/* List of GL enumerators */ + +/* The code below was genereated on Sun Feb 11 01:24:24 +0100 2007 + source: http://www.opengl.org/registry/api/enum.spec + http://www.opengl.org/registry/api/enumext.spec +*/ + #ifndef _GLENUMS_H_ #define _GLENUMS_H_ Index: ext/glut/mkrf_conf.rb =================================================================== --- ext/glut/mkrf_conf.rb (revision 171) +++ ext/glut/mkrf_conf.rb (working copy) @@ -20,6 +20,11 @@ case RUBY_PLATFORM when /darwin/ g.ldshared << ' -framework GLUT -framework OpenGL -framework Cocoa' + when /mswin32/ + g.cflags << ' -DWIN32' + g.include_library( 'glut32.lib', 'glutSolidTeapot' ) + g.include_library( 'glu32.lib', 'gluLookAt' ) + g.include_library( 'opengl32.lib', 'glVertex3d' ) else g.include_library( 'glut', 'glutSolidTeapot' ) g.include_library( 'GLU', 'gluLookAt' ) Index: ext/glut/glut.c =================================================================== --- ext/glut/glut.c (revision 171) +++ ext/glut/glut.c (working copy) @@ -35,6 +35,12 @@ #include +#ifdef WIN32 +#define DLLEXPORT __declspec(dllexport) +#else +#define DLLEXPORT +#endif + static int callId; /* 'call' method id */ /* callback define macro */ @@ -1484,7 +1490,7 @@ static VALUE module; -void Init_glut() +DLLEXPORT void Init_glut() { module = rb_define_module("Glut"); Index: Rakefile =================================================================== --- Rakefile (revision 171) +++ Rakefile (working copy) @@ -39,7 +39,8 @@ NICE_HTML_DOCS = WEBSITE_MKDN.ext('html') CLEAN.include("ext/gl*/Rakefile", "ext/*/mkrf.log", "ext/*/*.so", - "ext/**/*.bundle", "lib/*.so", "lib/*.bundle", "ext/*/*.o", + "ext/**/*.bundle", "lib/*.so", "lib/*.bundle", "ext/*/*.o{,bj}", + "ext/*/*.lib", "ext/*/*.exp", "ext/*/*.pdb", "pkg") CLOBBER.include("*.plain", "doc/*.plain", "doc/*.snip", "*.html", "doc/*.html", "website/*.html") @@ -125,7 +126,7 @@ # Define the files that will go into the gem gem_files = FileList["{lib,ext,doc,examples,test}/**/*"] -gem_files = gem_files.exclude("**/*.so", "**/*.o", "ext/**/*.log", "ext/gl*/Rakefile") +gem_files = gem_files.exclude("**/*.so", "**/*.o{,bj}", "ext/**/*.log", "ext/gl*/Rakefile") spec = Gem::Specification.new do |s| s.name = "ruby-opengl" From jan.dvorak at kraxnet.cz Thu Apr 5 10:26:00 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Thu, 5 Apr 2007 16:26:00 +0200 Subject: [ruby-opengl-devel] [Mkrf-users] Support for building on Windows In-Reply-To: <20070405101208.GI11974@best.ms.philips.com> References: <52DE1510-2435-4817-99E8-3D22F61C142C@alum.rpi.edu> <20070405101208.GI11974@best.ms.philips.com> Message-ID: <200704051626.00609.jan.dvorak@kraxnet.cz> On Thursday 05 April 2007 12:12, Ronald Pijnacker wrote: >I've attached the patch for making ruby-opengl build on windows. >This includes the patch Jan sent out last week that provides the extra >typedefs. Thanks. I've added your patch to the svn, seems working fine. Can you also provide detailed building instruction (and environment, eg. which compiler and version you used) for the bindings on windows ? We'll add them to the doc/build_install.txt > 2. The Init_opengl symbol can be dropped, I think, since the name of the > extension was changed into 'gl'. > > Just removing the Init_gl and Init_opengl from this file does not seem > to give any problems (which I expected). Yes, those are leftovers from the previous versions. > 3. How bad would it be to include rbogl.c in both gl and glu Rakefiles? > Although it would have to be built twice, it saves on Rakefile (in > common/) which currently is not auto-generated. Although it is technically possible, i would rather see the build system adjusted so it won't be needed. > 4. How does libruby.so.x.y.z get sucked in on the other architectures? > I seem to need to add this. > I think the symbols from libruby are resolved by dynamic linker when ruby loads the plugins (gl.so,glu.so ..), so libruby.so isn't needed at compile-time (only header files as ruby.h). I don't know how this translates to windows shared-lib building process though. Regards, Jan From pijnacker at dse.nl Thu Apr 5 13:40:17 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Thu, 5 Apr 2007 19:40:17 +0200 Subject: [ruby-opengl-devel] [Mkrf-users] Support for building on Windows In-Reply-To: <200704051626.00609.jan.dvorak@kraxnet.cz> References: <52DE1510-2435-4817-99E8-3D22F61C142C@alum.rpi.edu> <20070405101208.GI11974@best.ms.philips.com> <200704051626.00609.jan.dvorak@kraxnet.cz> Message-ID: <20070405174017.GA5296@localhost> > On Thursday 05 April 2007 12:12, Ronald Pijnacker wrote: > >I've attached the patch for making ruby-opengl build on windows. > >This includes the patch Jan sent out last week that provides the extra > >typedefs. > Thanks. I've added your patch to the svn, seems working fine. Can you also > provide detailed building instruction (and environment, eg. which compiler > and version you used) for the bindings on windows ? We'll add them to the > doc/build_install.txt Compiler tool-chain used: Microsoft Visual Studio 6.0. This should be the same version of Visual Studio as used during building ruby. If you do not use the same version, you'll get the error "MSC version mismatch" when including config.h via ruby.h. Mixing versions of visual studio is in general not to be recommended, since the corresponding c-runtimes are not compatible. It should be possible to build with only the compiler and linker by installing the SDK, but I have no experience with that. INCLUDE and LIB should be set correctly. This is easily done by invoking VCVARS32.bat from the VS instal directory. On most installations there is a start-menu entry "Visual Studio Command Line" for this. The INCLUDE variable should include the directory which has GL/glut.h. The LIB variable should include the directory which has glut32.lib (c:\ruby\bin when using the one-click-installer). Hopefully this is enough info, if not let me know what else you need. > > 2. The Init_opengl symbol can be dropped, I think, since the name of the > > extension was changed into 'gl'. > > > > Just removing the Init_gl and Init_opengl from this file does not seem > > to give any problems (which I expected). > Yes, those are leftovers from the previous versions. > > > 3. How bad would it be to include rbogl.c in both gl and glu Rakefiles? > > Although it would have to be built twice, it saves on Rakefile (in > > common/) which currently is not auto-generated. > Although it is technically possible, i would rather see the build system > adjusted so it won't be needed. The problem here is that mkrf only seems to generate rakefiles for dlls. The common/ directory only generates one object file. > > 4. How does libruby.so.x.y.z get sucked in on the other architectures? > > I seem to need to add this. > > > I think the symbols from libruby are resolved by dynamic linker when ruby > loads the plugins (gl.so,glu.so ..), so libruby.so isn't needed at > compile-time (only header files as ruby.h). I don't know how this translates > to windows shared-lib building process though. Now you mention it, I remember this from unix. Windows is different in that sense. When linking a dll all external symbols need to be resolved. Regards, Ronald From pijnacker at dse.nl Thu Apr 5 13:57:57 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Thu, 5 Apr 2007 19:57:57 +0200 Subject: [ruby-opengl-devel] Crash in glGetShaderInfoLog Message-ID: <20070405175757.GB5296@localhost> Hi all, I am experiencing a problem with glGetShaderInfoLog: a crash. I tried debugging through it, but I end up somewhere in the runtime, where I cannot follow what's going on anymore (somewhere in ruby_eval). Platform: windows ruby-opengl version: svn version r173. ruby: ruby 1.8.6 (one-click-installer) Any help would be appreciated. Also: I was expecting glGetShaderiv to return a bool when passing GL_COMPILE_STATUS. Instead I got 0, which passes through if ... Would it be feasible to return a boolean type when OpenGL docs specify that GL_TRUE or GL_FALSE is returned? Groeten, Ronald. From jan.dvorak at kraxnet.cz Thu Apr 5 14:29:30 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Thu, 5 Apr 2007 20:29:30 +0200 Subject: [ruby-opengl-devel] Crash in glGetShaderInfoLog In-Reply-To: <20070405175757.GB5296@localhost> References: <20070405175757.GB5296@localhost> Message-ID: <200704052029.30413.jan.dvorak@kraxnet.cz> On Thursday 05 April 2007 19:57, Ronald Pijnacker wrote: > Hi all, > > I am experiencing a problem with glGetShaderInfoLog: a crash. > I tried debugging through it, but I end up somewhere in the runtime, > where I cannot follow what's going on anymore (somewhere in ruby_eval). > > Platform: windows > ruby-opengl version: svn version r173. > ruby: ruby 1.8.6 (one-click-installer) > > Any help would be appreciated. Can you post the code (ar at least minimal testcase) ? I'm afraid any functionality from 1.1+ wasn't much tested (i was hoping to do that next week), although i got shader code running without problems. > Also: I was expecting glGetShaderiv to return a bool when passing > GL_COMPILE_STATUS. Instead I got 0, which passes through if ... > Would it be feasible to return a boolean type when OpenGL docs specify > that GL_TRUE or GL_FALSE is returned? That would require adding lots of code for each function that may return GLboolean, and also redefining GL_TRUE/FALSE itself to ruby bool. It would also make the code incompatible with C. I don't think that explicitly writing GL_TRUE/FALSE in conditions is that much of inconvenience :) - assuming GL_TRUE/FALSE to be equivalent to true/false isn't good practice even in C. Jan From pijnacker at dse.nl Thu Apr 5 16:01:06 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Thu, 5 Apr 2007 22:01:06 +0200 Subject: [ruby-opengl-devel] Crash in glGetShaderInfoLog In-Reply-To: <200704052029.30413.jan.dvorak@kraxnet.cz> References: <20070405175757.GB5296@localhost> <200704052029.30413.jan.dvorak@kraxnet.cz> Message-ID: <20070405200106.GL11974@best.ms.philips.com> > On Thursday 05 April 2007 19:57, Ronald Pijnacker wrote: > > Hi all, > > > > I am experiencing a problem with glGetShaderInfoLog: a crash. > > I tried debugging through it, but I end up somewhere in the runtime, > > where I cannot follow what's going on anymore (somewhere in ruby_eval). > > > > Platform: windows > > ruby-opengl version: svn version r173. > > ruby: ruby 1.8.6 (one-click-installer) > > > > Any help would be appreciated. > Can you post the code (ar at least minimal testcase) ? I'm afraid any > functionality from 1.1+ wasn't much tested (i was hoping to do that next > week), although i got shader code running without problems. I stripped it as much as possible. > > Also: I was expecting glGetShaderiv to return a bool when passing > > GL_COMPILE_STATUS. Instead I got 0, which passes through if ... > > Would it be feasible to return a boolean type when OpenGL docs specify > > that GL_TRUE or GL_FALSE is returned? > That would require adding lots of code for each function that may return > GLboolean, and also redefining GL_TRUE/FALSE itself to ruby bool. It would > also make the code incompatible with C. I don't think that explicitly writing > GL_TRUE/FALSE in conditions is that much of inconvenience :) - assuming > GL_TRUE/FALSE to be equivalent to true/false isn't good practice even in C. It is not so much that I mind typing == GL_TRUE (although I prefer not to) but I know I'll bump into that every now and then. I'll just have to try to remember. Ronald. -------------- next part -------------- require 'fox16'; include Fox require 'gl'; include Gl require 'glu'; include Glu $width = 800 $height = 800 VERTEX_SHADER_SOURCE = <<__VERTEX_SHADER_SOURCE__ void main(void) { gl_Position = ftransform(); } __VERTEX_SHADER_SOURCE__ FRAGMENT_SHADER_SOURCE = <<__FRAGMENT_SHADER_SOURCE__ void main(void) { gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0); } __FRAGMENT_SHADER_SOURCE__ class TestWindow < FXMainWindow def initialize(app) super(app, "Test Application", nil, nil, DECOR_ALL, 0, 0, $width, $height) @glvisual = FXGLVisual.new(app, VISUAL_DOUBLEBUFFER) @canvas = FXGLCanvas.new(self, @glvisual, nil, 0, LAYOUT_FILL_X|LAYOUT_FILL_Y|LAYOUT_TOP|LAYOUT_RIGHT) @canvas.connect(SEL_PAINT, method(:on_paint)) @canvas.connect(SEL_KEYPRESS, method(:on_keypress)) end def create super # Create the window show(PLACEMENT_SCREEN) # Make the main window appear end def setup_shader unless @program @vertex_shader = glCreateShader(GL_VERTEX_SHADER) @fragment_shader = glCreateShader(GL_FRAGMENT_SHADER) glShaderSource(@vertex_shader, VERTEX_SHADER_SOURCE) glShaderSource(@fragment_shader, FRAGMENT_SHADER_SOURCE) glCompileShader(@vertex_shader) ok1 = glGetShaderiv(@vertex_shader, GL_COMPILE_STATUS) raise unless ok1==1 puts glGetShaderInfoLog(@vertex_shader) glCompileShader(@fragment_shader) ok2 = glGetShaderiv(@fragment_shader, GL_COMPILE_STATUS) raise unless ok2==1 puts glGetShaderInfoLog(@fragment_shader) @program = glCreateProgram glAttachShader(@program, @vertex_shader) glAttachShader(@program, @fragment_shader) glLinkProgram(@program) ok = glGetProgramiv(@program, GL_LINK_STATUS) raise unless ok==1 end glUseProgram(@program) p glGetError end def on_keypress(sender, sel, event) case event.text when "q": exit end end def on_paint(sender, sel, event) width, height = @canvas.width, @canvas.height @canvas.makeCurrent setup_shader @canvas.swapBuffers if @glvisual.doubleBuffered? glFlush @canvas.makeNonCurrent end end application = FXApp.new("Test", "Test") window = TestWindow.new(application) application.create application.run From jan.dvorak at kraxnet.cz Sat Apr 7 18:43:10 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Sun, 8 Apr 2007 00:43:10 +0200 Subject: [ruby-opengl-devel] Crash in glGetShaderInfoLog In-Reply-To: <20070405200106.GL11974@best.ms.philips.com> References: <20070405175757.GB5296@localhost> <200704052029.30413.jan.dvorak@kraxnet.cz> <20070405200106.GL11974@best.ms.philips.com> Message-ID: <200704080043.10579.jan.dvorak@kraxnet.cz> On Thursday 05 April 2007 22:01, you wrote: > I stripped it as much as possible. Thanks. Unfortunately, i wasn't able to reproduce the crash, and frankly i have no idea why would it crash in the first place. I'm attaching patch where i rewrote the function and added another safeguard, but i don't think that should have any effect in the first place, but can you try it anyway ? Any other info you can produce (backtrack log, variable values at the time of crash) would be also nice. Thanks. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: buff.patch Type: text/x-diff Size: 1106 bytes Desc: not available Url : http://rubyforge.org/pipermail/ruby-opengl-devel/attachments/20070408/a9650120/attachment.bin From jan.dvorak at kraxnet.cz Wed Apr 11 09:06:42 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Wed, 11 Apr 2007 15:06:42 +0200 Subject: [ruby-opengl-devel] Crash in glGetShaderInfoLog In-Reply-To: <20070410074546.GA14908@best.ms.philips.com> References: <20070405175757.GB5296@localhost> <200704080043.10579.jan.dvorak@kraxnet.cz> <20070410074546.GA14908@best.ms.philips.com> Message-ID: <200704111506.42166.jan.dvorak@kraxnet.cz> On Tuesday 10 April 2007 09:45, you wrote: > I tried running with your patch applied. This time it did not crash > anymore, but it hung the process. > Running in the debugger led to strange results: while stepping through > the xfree function, I ended up in rb_str_new. > > Since this smells like memory gone bad, I ran it though purify. This > warns about beyond stack write problems, but I really do not understand > why. I've attached a purify screenshot that shows the problem. > > Possibly there is something corrupted in the ruby-runtime, which > triggers these strange problems. However, I have no clue where to look. The problem with stack corruption is it is very hard to find where exactly it happens as it is usually caught much later in execution by malloc/free. It may be in the ruby runtime, it may be in the fox library, it may be in our bindings, but it may also be in the underlying opengl implementation (drivers). I've tried to trace it on linux with valgrind, but there seems to be no problem, so i'll try it tommorrow on windows installation to see if thats any different. Can you try to write/run the same code without the fox library (only with glut) to eliminate one of the possibilities ? Thanks. Jan From pijnacker at dse.nl Wed Apr 11 09:26:17 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Wed, 11 Apr 2007 15:26:17 +0200 Subject: [ruby-opengl-devel] Crash in glGetShaderInfoLog In-Reply-To: <200704111506.42166.jan.dvorak@kraxnet.cz> References: <20070405175757.GB5296@localhost> <200704080043.10579.jan.dvorak@kraxnet.cz> <20070410074546.GA14908@best.ms.philips.com> <200704111506.42166.jan.dvorak@kraxnet.cz> Message-ID: <20070411132617.GD14908@best.ms.philips.com> Jan, > On Tuesday 10 April 2007 09:45, you wrote: > > I tried running with your patch applied. This time it did not crash > > anymore, but it hung the process. > > Running in the debugger led to strange results: while stepping through > > the xfree function, I ended up in rb_str_new. > > > > Since this smells like memory gone bad, I ran it though purify. This > > warns about beyond stack write problems, but I really do not understand > > why. I've attached a purify screenshot that shows the problem. > > > > Possibly there is something corrupted in the ruby-runtime, which > > triggers these strange problems. However, I have no clue where to look. > > The problem with stack corruption is it is very hard to find where exactly it > happens as it is usually caught much later in execution by malloc/free. It > may be in the ruby runtime, it may be in the fox library, it may be in our > bindings, but it may also be in the underlying opengl implementation > (drivers). I've tried to trace it on linux with valgrind, but there seems to > be no problem, so i'll try it tommorrow on windows installation to see if > thats any different. Can you try to write/run the same code without the fox > library (only with glut) to eliminate one of the possibilities ? Thanks. It does not seem to matter much. Also with glut, the program seems to hang. I've attached the glut version of the program for you to try. Ronald. -------------- next part -------------- require 'gl'; include Gl require 'glu'; include Glu require 'glut'; include Glut VERTEX_SHADER_SOURCE = <<__VERTEX_SHADER_SOURCE__ void main(void) { gl_Position = ftransform(); } __VERTEX_SHADER_SOURCE__ FRAGMENT_SHADER_SOURCE = <<__FRAGMENT_SHADER_SOURCE__ void main(void) { gl_FragColor = vec4(1.0, 1.0, 1.0, 1.0); } __FRAGMENT_SHADER_SOURCE__ def init_gl_window(width = 640, height = 480) unless @program @vertex_shader = glCreateShader(GL_VERTEX_SHADER) @fragment_shader = glCreateShader(GL_FRAGMENT_SHADER) glShaderSource(@vertex_shader, VERTEX_SHADER_SOURCE) glShaderSource(@fragment_shader, FRAGMENT_SHADER_SOURCE) glCompileShader(@vertex_shader) ok1 = glGetShaderiv(@vertex_shader, GL_COMPILE_STATUS) raise unless ok1==1 puts glGetShaderInfoLog(@vertex_shader) glCompileShader(@fragment_shader) ok2 = glGetShaderiv(@fragment_shader, GL_COMPILE_STATUS) raise unless ok2==1 puts glGetShaderInfoLog(@fragment_shader) @program = glCreateProgram glAttachShader(@program, @vertex_shader) glAttachShader(@program, @fragment_shader) glLinkProgram(@program) ok = glGetProgramiv(@program, GL_LINK_STATUS) raise unless ok==1 end glUseProgram(@program) p glGetError end def draw_gl_scene # Clear the screen and depth buffer glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) # Swap buffers for display glutSwapBuffers end # The idle function to handle def idle glutPostRedisplay end # Keyboard handler to exit when ESC is typed keyboard = lambda do |key, x, y| case(key) when 27 glutDestroyWindow(window) exit(0) end glutPostRedisplay end # Initliaze our GLUT code glutInit # Setup a double buffer, RGBA color, alpha components and depth buffer glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_ALPHA | GLUT_DEPTH) glutInitWindowSize(640, 480) glutInitWindowPosition(0, 0) window = glutCreateWindow("crash test") glutDisplayFunc(method(:draw_gl_scene).to_proc) glutIdleFunc(method(:idle).to_proc) glutKeyboardFunc(keyboard) init_gl_window(640, 480) glutMainLoop() From pijnacker at dse.nl Thu Apr 19 15:16:00 2007 From: pijnacker at dse.nl (Ronald Pijnacker) Date: Thu, 19 Apr 2007 21:16:00 +0200 Subject: [ruby-opengl-devel] Crash in glGetShaderInfoLog -- SOLVED In-Reply-To: <200704111506.42166.jan.dvorak@kraxnet.cz> References: <20070405175757.GB5296@localhost> <200704080043.10579.jan.dvorak@kraxnet.cz> <20070410074546.GA14908@best.ms.philips.com> <200704111506.42166.jan.dvorak@kraxnet.cz> Message-ID: <20070419191600.GA6140@localhost> > On Tuesday 10 April 2007 09:45, you wrote: > > I tried running with your patch applied. This time it did not crash > > anymore, but it hung the process. > > Running in the debugger led to strange results: while stepping through > > the xfree function, I ended up in rb_str_new. > > > > Since this smells like memory gone bad, I ran it though purify. This > > warns about beyond stack write problems, but I really do not understand > > why. I've attached a purify screenshot that shows the problem. > > > > Possibly there is something corrupted in the ruby-runtime, which > > triggers these strange problems. However, I have no clue where to look. > > The problem with stack corruption is it is very hard to find where exactly it > happens as it is usually caught much later in execution by malloc/free. It > may be in the ruby runtime, it may be in the fox library, it may be in our > bindings, but it may also be in the underlying opengl implementation > (drivers). I've tried to trace it on linux with valgrind, but there seems to > be no problem, so i'll try it tommorrow on windows installation to see if > thats any different. Can you try to write/run the same code without the fox > library (only with glut) to eliminate one of the possibilities ? Thanks. Found! The problem had to do with calling conventions. When I tried to isolate the crash in a small c-program, the same thing happened. Adding APIENTRY to the function-pointer declaration fixed the problem. Should I send in a patch for this, or will someone else pick this up? Regards, Ronald. From jan.dvorak at kraxnet.cz Thu Apr 19 16:55:50 2007 From: jan.dvorak at kraxnet.cz (Jan Dvorak) Date: Thu, 19 Apr 2007 22:55:50 +0200 Subject: [ruby-opengl-devel] Crash in glGetShaderInfoLog -- SOLVED In-Reply-To: <20070419191600.GA6140@localhost> References: <20070405175757.GB5296@localhost> <200704111506.42166.jan.dvorak@kraxnet.cz> <20070419191600.GA6140@localhost> Message-ID: <200704192255.50150.jan.dvorak@kraxnet.cz> On Thursday 19 April 2007 21:16, Ronald Pijnacker wrote: > Found! > The problem had to do with calling conventions. When I tried to isolate > the crash in a small c-program, the same thing happened. Adding APIENTRY > to the function-pointer declaration fixed the problem. Good to hear. > Should I send in a patch for this, or will someone else pick this up? Please do. Thanks. Jan