Re: [Pharo-dev] NBOpenGL on Windows

2014-03-17 Thread Igor Stasenko
https://ci.inria.fr/pharo-contribution/job/NBOpenGL/


On 16 March 2014 00:02, Nicolai Hess nicolaih...@web.de wrote:

 Is there a working version (maybe with examples)
 for NBOpenGL on Windows?





-- 
Best regards,
Igor Stasenko.


Re: [Pharo-dev] NBOpenGL on Windows

2014-03-17 Thread Igor Stasenko
On 17 March 2014 12:13, Nicolai Hess nicolaih...@web.de wrote:


 2014-03-17 11:49 GMT+01:00 Igor Stasenko siguc...@gmail.com:

 https://ci.inria.fr/pharo-contribution/job/NBOpenGL/


 On 16 March 2014 00:02, Nicolai Hess nicolaih...@web.de wrote:

 Is there a working version (maybe with examples)
 for NBOpenGL on Windows?





 --
 Best regards,
 Igor Stasenko.



 Thank you Igor,

 now the question is, what to do with this?
 It looks like the same version I would get on installing Roassal3D, which
 doesn't
 work (all windows are empty).

 Running
 GLViewportMorph new openInWorld
 or
 GLTTRenderingDemo new openInWorld
 results in an error
 NBGLFrameBuffer(Object)error:
 'Frame buffer is incomplete: GL_FRAMEBUFFER_UNSUPPORTED'


so your graphics card/driver don't supports requested configuration of
framebuffer used in demo.

all you have to do is to implement own, which will work on your machine.
since you got that message, the NBOpenGL works fine.



 Nicolai






-- 
Best regards,
Igor Stasenko.


Re: [Pharo-dev] NBOpenGL on Windows

2014-03-17 Thread Igor Stasenko
On 17 March 2014 16:57, Ben Coman b...@openinworld.com wrote:


 As NBOpenBL gets broader use by end-users of applications like Roassal,
 there is a good chance of a flood of these reports.  Maybe too late to get
 into Pharo3, but it would good (if possible) for system checking be built
 in to determine the feature support of a user's graphic card.

 Alternatively, such reports might be reduced with better indication its a
 lack of feature rather than an error.
 For example:
 NBGLFrameBuffer(Object)unspportedFeature:
 looks better than :
 NBGLFrameBuffer(Object)error:


What does it changes? This error is going from OpenGL itself.
GL_FRAMEBUFFER_UNSUPPORTED is a constant reported by opengl..
are you going to introduce separate error-handling method for each and
every possible error code which opengl produces (includes hundreds of
extensions and more coming each year) ?
If yes, then i wish you good luck! :)

The complete error description can be found in corresponding OpenGL
documentation. As well as recommendations what to do and what not. And i am
not going to teach how to use OpenGL library. ;)



 cheers -ben


 In another thread Ronie Salgado wrote:

  Hi Nicolai,

  What are your system specs?, specially your graphic card.
  Roassal3D requires a graphic card with at least OpenGL 2.0 support. Try
 updating your graphic drivers

  Greetings,
  Ronie



 This thread Igor Stasenko wrote:




 On 17 March 2014 12:13, Nicolai Hess nicolaih...@web.de wrote:


 2014-03-17 11:49 GMT+01:00 Igor Stasenko siguc...@gmail.com:

  https://ci.inria.fr/pharo-contribution/job/NBOpenGL/


 On 16 March 2014 00:02, Nicolai Hess nicolaih...@web.de wrote:

 Is there a working version (maybe with examples)
 for NBOpenGL on Windows?





  --
 Best regards,
 Igor Stasenko.



  Thank you Igor,

  now the question is, what to do with this?
  It looks like the same version I would get on installing Roassal3D,
 which doesn't
  work (all windows are empty).

  Running
  GLViewportMorph new openInWorld
  or
 GLTTRenderingDemo new openInWorld
 results in an error
 NBGLFrameBuffer(Object)error:
 'Frame buffer is incomplete: GL_FRAMEBUFFER_UNSUPPORTED'


 so your graphics card/driver don't supports requested configuration of
 framebuffer used in demo.

  all you have to do is to implement own, which will work on your machine.
  since you got that message, the NBOpenGL works fine.



  Nicolai






 --
 Best regards,
 Igor Stasenko.





-- 
Best regards,
Igor Stasenko.


Re: [Pharo-dev] NBOpenGL on Windows

2014-03-17 Thread Nicolai Hess
2014-03-17 18:09 GMT+01:00 Igor Stasenko siguc...@gmail.com:




 On 17 March 2014 16:57, Ben Coman b...@openinworld.com wrote:


 As NBOpenBL gets broader use by end-users of applications like Roassal,
 there is a good chance of a flood of these reports.  Maybe too late to get
 into Pharo3, but it would good (if possible) for system checking be built
 in to determine the feature support of a user's graphic card.

 Alternatively, such reports might be reduced with better indication its a
 lack of feature rather than an error.
 For example:
 NBGLFrameBuffer(Object)unspportedFeature:
 looks better than :
 NBGLFrameBuffer(Object)error:


 What does it changes? This error is going from OpenGL itself.
 GL_FRAMEBUFFER_UNSUPPORTED is a constant reported by opengl..
 are you going to introduce separate error-handling method for each and
 every possible error code which opengl produces (includes hundreds of
 extensions and more coming each year) ?
 If yes, then i wish you good luck! :)

 The complete error description can be found in corresponding OpenGL
 documentation. As well as recommendations what to do and what not. And i am
 not going to teach how to use OpenGL library. ;)



 cheers -ben


 In another thread Ronie Salgado wrote:

  Hi Nicolai,

  What are your system specs?, specially your graphic card.
  Roassal3D requires a graphic card with at least OpenGL 2.0 support. Try
 updating your graphic drivers

  Greetings,
  Ronie



 This thread Igor Stasenko wrote:




 On 17 March 2014 12:13, Nicolai Hess nicolaih...@web.de wrote:


 2014-03-17 11:49 GMT+01:00 Igor Stasenko siguc...@gmail.com:

  https://ci.inria.fr/pharo-contribution/job/NBOpenGL/


 On 16 March 2014 00:02, Nicolai Hess nicolaih...@web.de wrote:

 Is there a working version (maybe with examples)
 for NBOpenGL on Windows?





  --
 Best regards,
 Igor Stasenko.



  Thank you Igor,

  now the question is, what to do with this?
  It looks like the same version I would get on installing Roassal3D,
 which doesn't
  work (all windows are empty).

  Running
  GLViewportMorph new openInWorld
  or
 GLTTRenderingDemo new openInWorld
 results in an error
 NBGLFrameBuffer(Object)error:
 'Frame buffer is incomplete: GL_FRAMEBUFFER_UNSUPPORTED'


 so your graphics card/driver don't supports requested configuration of
 framebuffer used in demo.

  all you have to do is to implement own, which will work on your machine.
  since you got that message, the NBOpenGL works fine.



  Nicolai






 --
 Best regards,
 Igor Stasenko.





 --
 Best regards,
 Igor Stasenko.



Ok, looks like it is a driver issue. On another windows machine, creating
the frame buffer object works
(no more GL_FRAMEBUFFER_UNSUPPORTED error). But the rendering looks
strange, this is not how
it is supposed to look, right?

Screenshot attached:
attachment: glttrenderingdemo.png

Re: [Pharo-dev] NBOpenGL on Windows

2014-03-17 Thread Igor Stasenko
On 17 March 2014 20:50, Nicolai Hess nicolaih...@web.de wrote:

 2014-03-17 18:09 GMT+01:00 Igor Stasenko siguc...@gmail.com:




 On 17 March 2014 16:57, Ben Coman b...@openinworld.com wrote:


 As NBOpenBL gets broader use by end-users of applications like Roassal,
 there is a good chance of a flood of these reports.  Maybe too late to get
 into Pharo3, but it would good (if possible) for system checking be built
 in to determine the feature support of a user's graphic card.

 Alternatively, such reports might be reduced with better indication its
 a lack of feature rather than an error.
 For example:
 NBGLFrameBuffer(Object)unspportedFeature:
 looks better than :
 NBGLFrameBuffer(Object)error:


 What does it changes? This error is going from OpenGL itself.
 GL_FRAMEBUFFER_UNSUPPORTED is a constant reported by opengl..
 are you going to introduce separate error-handling method for each and
 every possible error code which opengl produces (includes hundreds of
 extensions and more coming each year) ?
 If yes, then i wish you good luck! :)

 The complete error description can be found in corresponding OpenGL
 documentation. As well as recommendations what to do and what not. And i am
 not going to teach how to use OpenGL library. ;)



 cheers -ben


 In another thread Ronie Salgado wrote:

  Hi Nicolai,

  What are your system specs?, specially your graphic card.
  Roassal3D requires a graphic card with at least OpenGL 2.0 support.
 Try updating your graphic drivers

  Greetings,
  Ronie



 This thread Igor Stasenko wrote:




 On 17 March 2014 12:13, Nicolai Hess nicolaih...@web.de wrote:


 2014-03-17 11:49 GMT+01:00 Igor Stasenko siguc...@gmail.com:

  https://ci.inria.fr/pharo-contribution/job/NBOpenGL/


 On 16 March 2014 00:02, Nicolai Hess nicolaih...@web.de wrote:

 Is there a working version (maybe with examples)
 for NBOpenGL on Windows?





  --
 Best regards,
 Igor Stasenko.



  Thank you Igor,

  now the question is, what to do with this?
  It looks like the same version I would get on installing Roassal3D,
 which doesn't
  work (all windows are empty).

  Running
  GLViewportMorph new openInWorld
  or
 GLTTRenderingDemo new openInWorld
 results in an error
 NBGLFrameBuffer(Object)error:
 'Frame buffer is incomplete: GL_FRAMEBUFFER_UNSUPPORTED'


 so your graphics card/driver don't supports requested configuration of
 framebuffer used in demo.

  all you have to do is to implement own, which will work on your
 machine.
  since you got that message, the NBOpenGL works fine.



  Nicolai






 --
 Best regards,
 Igor Stasenko.





 --
 Best regards,
 Igor Stasenko.



 Ok, looks like it is a driver issue. On another windows machine, creating
 the frame buffer object works
 (no more GL_FRAMEBUFFER_UNSUPPORTED error). But the rendering looks
 strange, this is not how
 it is supposed to look, right?

 Screenshot attached:


not quite, but at least it is functional. Maybe there was changes in code
which causing artifacts.

-- 
Best regards,
Igor Stasenko.


[Pharo-dev] NBOpenGL on Windows

2014-03-15 Thread Nicolai Hess
Is there a working version (maybe with examples)
for NBOpenGL on Windows?


Re: [Pharo-dev] NBOpenGL commit permissions

2013-12-15 Thread Stéphane Ducasse
done 
try and let me know.

On Dec 15, 2013, at 12:35 AM, Ronie Salgado ronies...@gmail.com wrote:

 Hello,
 
 I would like to request commit privileges to the PharoExtra/NBOpenGL 
 smalltalk hub project, so that I can commit improvements made for Roassal 3D, 
 but useful for anyone.
 
 My SmalltalkHub username is 'ronsaldo'.
 
 Greetings,
 Ronie Salgado




Re: [Pharo-dev] NBOpenGL VM crash.

2013-11-08 Thread Stéphane Ducasse
Igor 

Ronnie will come to work with you in January :) you do not know it but ronnie 
loves 3D and openGL.

:)

On Nov 6, 2013, at 10:57 AM, Igor Stasenko siguc...@gmail.com wrote:

 According to dump, it crashes during call to:
 
   0x21d8c8 I NBWndClassEx classunregister:instance: 0x10f7e7cc: a(n) 
 NBWndClassEx class
 
 the reason could be that you passing wrong handle which not exists (or was 
 existed in previous image session but invalid now).
 
 Not much else i can say without having image and trying myself.
 
 
 
 On 6 November 2013 03:42, Ronie Salgado ronies...@gmail.com wrote:
 I'm trying to use the latest version of NBOpenGL in Windows in Pharo 3.0.
 First I'm receiving a Not suitable implementation error message. This can 
 be solved by adding the following at the class side of NBWin32GLContextDriver.
 
 NBWin32GLContextDriversupportsCurrentPlatform
 ^ NativeBoost platformId = NativeBoostConstants win32PlatformId
 
 Then, trying the following Roassal3D example produces a VM crash:
 
 R3Example new city
 
 Attached is the crash.dmp file. Currently, we are using an old pharo image 
 for developing Roassal3D under windows.
 
 Greetings,
 Ronie Salgado
 
 
 
 -- 
 Best regards,
 Igor Stasenko.



Re: [Pharo-dev] NBOpenGL VM crash.

2013-11-06 Thread Igor Stasenko
According to dump, it crashes during call to:

  0x21d8c8 I NBWndClassEx classunregister:instance: 0x10f7e7cc: a(n)
NBWndClassEx class

the reason could be that you passing wrong handle which not exists (or was
existed in previous image session but invalid now).

Not much else i can say without having image and trying myself.



On 6 November 2013 03:42, Ronie Salgado ronies...@gmail.com wrote:

 I'm trying to use the latest version of NBOpenGL in Windows in Pharo 3.0.
 First I'm receiving a Not suitable implementation error message. This
 can be solved by adding the following at the class side of
 NBWin32GLContextDriver.

 NBWin32GLContextDriversupportsCurrentPlatform
 ^ NativeBoost platformId = NativeBoostConstants win32PlatformId

 Then, trying the following Roassal3D example produces a VM crash:

 R3Example new city

 Attached is the crash.dmp file. Currently, we are using an old pharo image
 for developing Roassal3D under windows.

 Greetings,
 Ronie Salgado




-- 
Best regards,
Igor Stasenko.


Re: [Pharo-dev] NBOpenGL VM crash.

2013-11-06 Thread Ronie Salgado
I placed an image in my dropbox which reproduces the problem:
https://www.dropbox.com/s/7bfdpu4eqrmb7vt/crash-NBOpenGL.zip

Greetings,
Ronie Salgado


2013/11/6 Igor Stasenko siguc...@gmail.com

 According to dump, it crashes during call to:

   0x21d8c8 I NBWndClassEx classunregister:instance: 0x10f7e7cc: a(n)
 NBWndClassEx class

 the reason could be that you passing wrong handle which not exists (or was
 existed in previous image session but invalid now).

 Not much else i can say without having image and trying myself.



 On 6 November 2013 03:42, Ronie Salgado ronies...@gmail.com wrote:

 I'm trying to use the latest version of NBOpenGL in Windows in Pharo 3.0.
 First I'm receiving a Not suitable implementation error message. This
 can be solved by adding the following at the class side of
 NBWin32GLContextDriver.

 NBWin32GLContextDriversupportsCurrentPlatform
 ^ NativeBoost platformId = NativeBoostConstants win32PlatformId

 Then, trying the following Roassal3D example produces a VM crash:

 R3Example new city

 Attached is the crash.dmp file. Currently, we are using an old pharo
 image for developing Roassal3D under windows.

 Greetings,
 Ronie Salgado




 --
 Best regards,
 Igor Stasenko.



Re: [Pharo-dev] NBOpengl Error : IcompatibleLayoutConflict

2013-09-12 Thread Igor Stasenko
This should be fixed. It easy to fix, just had no time to update things in
all projects.
Basically, what needed is to save package version, which has
no subclasses of NBExternalStructure,
and then take new image and manually reintroduce all NBExternalStructure
subclasses (use fileout/filein mechanism)
and then save a new MC packages, where these classes in right format.

Please read details here:
https://groups.google.com/forum/#!topic/nativeboost/3Ik3UtLGMGo


On 12 September 2013 09:34, kilon theki...@yahoo.co.uk wrote:

 ok so you talk about live objects, i see. Nonetheless I assume that it will
 still install NBOpenGL fully without any problems. The problem is instance
 objects that I may be using at the time.



 --
 View this message in context:
 http://forum.world.st/NBOpengl-Error-IcompatibleLayoutConflict-tp4707721p4707786.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.




-- 
Best regards,
Igor Stasenko.


Re: [Pharo-dev] NBOpengl Error : IcompatibleLayoutConflict

2013-09-11 Thread kilon
So this mean this is more of a warning than an error and it does not really
affect the installation of NBOpenGL ? 

and what it means by invalid state for a small period ? is that a bytecode
issue or an object issue ?
 

Camillo Bruni-3 wrote
 yeah we have to have solve this somehow, it is a side-effect of the new
 class-builder
 which actually properly validates the layouts of classes.
 
 If you modify classes with monticello they might end up in an invalid
 state for a short
 period. Previously this went undetected, the SlotClassBuilder is very
 picky about this :(.
 
 Maybe an intermediate solution for this is to disable any kind of
 validation while we
 load stuff with Monticello...
 
 On 2013-09-11, at 15:13, kilon lt;

 thekilon@.co

 gt; wrote:
 
 IcompatibleLayoutConflict: Class with PointerLayout cannot be extended as
 byte
 
 is the error i am getting using the very latest pharo 3.0 image while
 trying
 to load NBOpengl
 
 (ConfigurationOfNBOpenGL project version: '2.0') load.
 
 here is the full trace
 
 http://pastebin.com/an4KFVrH
 
 I get the same error in macos and ubuntu, I suspect windoom is same too. 
 
 
 
 
 --
 View this message in context:
 http://forum.world.st/NBOpengl-Error-IcompatibleLayoutConflict-tp4707721.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.
 
 
 
 
 signature.asc (457 bytes)
 lt;http://forum.world.st/attachment/4707735/0/signature.ascgt;





--
View this message in context: 
http://forum.world.st/NBOpengl-Error-IcompatibleLayoutConflict-tp4707721p4707745.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.



Re: [Pharo-dev] NBOpengl Error : IcompatibleLayoutConflict

2013-09-11 Thread Camillo Bruni
yeah we have to have solve this somehow, it is a side-effect of the new 
class-builder
which actually properly validates the layouts of classes.

If you modify classes with monticello they might end up in an invalid state for 
a short
period. Previously this went undetected, the SlotClassBuilder is very picky 
about this :(.

Maybe an intermediate solution for this is to disable any kind of validation 
while we
load stuff with Monticello...

On 2013-09-11, at 15:13, kilon theki...@yahoo.co.uk wrote:

 IcompatibleLayoutConflict: Class with PointerLayout cannot be extended as
 byte
 
 is the error i am getting using the very latest pharo 3.0 image while trying
 to load NBOpengl
 
 (ConfigurationOfNBOpenGL project version: '2.0') load.
 
 here is the full trace
 
 http://pastebin.com/an4KFVrH
 
 I get the same error in macos and ubuntu, I suspect windoom is same too. 
 
 
 
 
 --
 View this message in context: 
 http://forum.world.st/NBOpengl-Error-IcompatibleLayoutConflict-tp4707721.html
 Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
 



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Pharo-dev] NBOpengl Error : IcompatibleLayoutConflict

2013-09-11 Thread Camillo Bruni
Well no it is an error since the classes are in an invalid state.

It is not possible to do all migrations with Monticello and keep all
classes in a sane condition all the time. Just image moving an instance
variable from a subclass which is in one monticello package B to a superclass
which is in another package A. If the default load order is A - B then you 
will have all of a sudden a double variable declaration. 

In any case, the old class builder was very permissive and it even let you
continue to work with classes with invalid layout states (for instance the
duplicate variables, or incompatibly subclass layouts).

For as long as you don't have instances and you do not use these classes there
is not really a problem.


On 2013-09-11, at 16:31, kilon theki...@yahoo.co.uk wrote:
 So this mean this is more of a warning than an error and it does not really
 affect the installation of NBOpenGL ? 
 
 and what it means by invalid state for a small period ? is that a bytecode
 issue or an object issue ?
 
 
 Camillo Bruni-3 wrote
 yeah we have to have solve this somehow, it is a side-effect of the new
 class-builder
 which actually properly validates the layouts of classes.
 
 If you modify classes with monticello they might end up in an invalid
 state for a short
 period. Previously this went undetected, the SlotClassBuilder is very
 picky about this :(.
 
 Maybe an intermediate solution for this is to disable any kind of
 validation while we
 load stuff with Monticello...
 
 On 2013-09-11, at 15:13, kilon lt;
 
 thekilon@.co
 
 gt; wrote:
 
 IcompatibleLayoutConflict: Class with PointerLayout cannot be extended as
 byte
 
 is the error i am getting using the very latest pharo 3.0 image while
 trying
 to load NBOpengl
 
 (ConfigurationOfNBOpenGL project version: '2.0') load.
 
 here is the full trace
 
 http://pastebin.com/an4KFVrH
 
 I get the same error in macos and ubuntu, I suspect windoom is same too. 
 
 
 
 
 --
 View this message in context:
 http://forum.world.st/NBOpengl-Error-IcompatibleLayoutConflict-tp4707721.html
 Sent from the Pharo Smalltalk Developers mailing list archive at
 Nabble.com.
 
 
 
 
 signature.asc (457 bytes)
 lt;http://forum.world.st/attachment/4707735/0/signature.ascgt;
 
 
 
 
 
 --
 View this message in context: 
 http://forum.world.st/NBOpengl-Error-IcompatibleLayoutConflict-tp4707721p4707745.html
 Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
 



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Pharo-dev] NBOpenGL

2013-06-19 Thread Alexandre Bergel
 Are there some resources that are not freed when I saved my image? How can I 
 reset them?
 
 According to your log,  NB cannot get source code of methods. make
 sure .source and .changes
 files are accessible to image.

Ah yes!

Thanks Igor!

Cheers,
Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Re: [Pharo-dev] NBOpenGL

2013-06-18 Thread Igor Stasenko
On 17 June 2013 21:24, Alexandre Bergel alexandre.ber...@me.com wrote:
 Hi Igor,

 I currently have two students who are very motivated in working with the open 
 gl binding.
 However we are experiencing stability problems. Last week I created a moose 
 image with NBOpenGL and SourceCity and it worked well SourceCity 
 exampleRpackage gave me the beautiful visualization.

 Today I cannot open the image anymore. I got the diabolic error Could not 
 find accessor for variable named aModuleName in NativeBoost. I have 
 attached a .log file. Do you have any idea what is going on?



 Are there some resources that are not freed when I saved my image? How can I 
 reset them?

According to your log,  NB cannot get source code of methods. make
sure .source and .changes
files are accessible to image.

 Cheers,
 Alexandre
 --
 _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
 Alexandre Bergel  http://www.bergel.eu
 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.





-- 
Best regards,
Igor Stasenko.



[Pharo-dev] NBOpenGL

2013-06-17 Thread Alexandre Bergel
Hi Igor,

I currently have two students who are very motivated in working with the open 
gl binding.
However we are experiencing stability problems. Last week I created a moose 
image with NBOpenGL and SourceCity and it worked well SourceCity 
exampleRpackage gave me the beautiful visualization.

Today I cannot open the image anymore. I got the diabolic error Could not find 
accessor for variable named aModuleName in NativeBoost. I have attached a 
.log file. Do you have any idea what is going on? 

Are there some resources that are not freed when I saved my image? How can I 
reset them?

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




PharoDebug.log
Description: Binary data