[Pharo-project] Understanding NBOpenGL
Ok so I tried to learn Opengl ES 2 (and opengl 4) during my eastern vacations because I realised that I dont really need Athens or vector graphics for my GUI , since I will be dealing mostly with 3d graphics anyway. (My project "ephestos" will be an effort of creating a 3d app for pharo, see also "blender") So when I tried to run the demos i get an error with NBMacGLContextDriver>>supportsCurrentPlatform "obviously, for Mac intel-32 only :)" ^ NativeBoost platformId = NativeBoostConstants mac32PlaformId My mac is "obviously" not 32-bit but 64 bit, but I dont know if that matters since pharo is only 32 bit anyway. The bug is also obvious it should be mac32PlatformId and not mac32PlaformId. I correct and proceed and gives me a new error this time in NBMacGlApi>>glApiCall: fnSpec index: fnIndex attributes: attributes context: contextToRetry ^[ (NBCallFailureHandler for: contextToRetry) retryWith: [ :targetClass :targetMethod | (NBFFICallout targetClass: targetClass targetMethod: targetMethod fnSpec: fnSpec) stdcall; generate: [ :gen | self emitCall: fnIndex generator: gen ] ] ] on: NBNativeCodeError do: [:err :handler | err errorCode = ErrorFnNotAvailable ifTrue: [ "Native code is installed, but function pointer not loaded yet. Try to load function and retry the call" (self tryGetFunctionPointer: (self class glFunctions at: fnIndex)) ifFalse: [ ^ err pass ]. ^ handler retrySend ]. err pass ] The problem here that NBCallFailureHandler is nowhere to be found. At first I though my NB was lagging behind in version so I download from smalltalk Hub and did ConfigurationOfNativeboost loadStable. it updated without errors but still that class is nowhere to be found. So my question is this, does it really worth it to struggle with NBOpengl or will it better to learn how Nativeboost works and use Opengl myself ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 9 May 2013 00:04, kilon <thekilon@yahoo.co.uk> wrote:
Ok so I tried to learn Opengl ES 2 (and opengl 4) during my eastern vacations because I realised
that I dont really need Athens or vector graphics for my GUI , since I will be dealing mostly with 3d graphics anyway. (My project "ephestos" will be an effort of creating a 3d app for pharo, see also "blender")
well, Athens provides convenient API for 2d vector graphics, which not exists in opengl .. One day i want to begin implementing opengl backend for Athens.
So when I tried to run the demos i get an error with
NBMacGLContextDriver>>supportsCurrentPlatform "obviously, for Mac intel-32 only :)" ^ NativeBoost platformId = NativeBoostConstants mac32PlaformId
My mac is "obviously" not 32-bit but 64 bit, but I dont know if that matters since pharo is only 32 bit anyway. The bug is also obvious it should be mac32PlatformId and not mac32PlaformId.
I correct and proceed and gives me a new error this time in
NBMacGlApi>>glApiCall: fnSpec index: fnIndex attributes: attributes context: contextToRetry
^[ (NBCallFailureHandler for: contextToRetry) retryWith: [ :targetClass :targetMethod | (NBFFICallout targetClass: targetClass targetMethod: targetMethod fnSpec: fnSpec) stdcall; generate: [ :gen | self emitCall: fnIndex generator: gen ] ] ] on: NBNativeCodeError do: [:err :handler | err errorCode = ErrorFnNotAvailable ifTrue: [ "Native code is installed, but function pointer not loaded yet. Try to load function and retry the call" (self tryGetFunctionPointer: (self class glFunctions at: fnIndex)) ifFalse: [ ^ err pass ]. ^ handler retrySend ]. err pass ]
The problem here that NBCallFailureHandler is nowhere to be found. At first I though my NB was lagging behind in version so I download from smalltalk Hub and did
ConfigurationOfNativeboost loadStable.
Neither my image has "NBCallFailureHandler". Looks like you loaded wrong version of NBOpenGL. How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load it should work out of the box. (and you don't need to load NativeBoost, because it is already in image).
it updated without errors but still that class is nowhere to be found.
So my question is this, does it really worth it to struggle with NBOpengl or will it better to learn how Nativeboost works and use Opengl myself ?
That what exactly NBOpenGL is. Its contents is bindings to OpenGL library (over 3000 functions) the rest is glue code , which mostly serves as an example how to create and initialize opengl context depending on platform you using. The subcategory "NBOpenGL-Display" contains root classes with that glue code. While NBOpenGL-Core is 99% is just plain opengl api. If you don't like this glue, you can just avoid using it.. but throwing away opengl core and making own.. makes little sense. I actually encouraged people to write better glue code for initializing context.. The main problem is that its highly platform specific.. and my knowledge doesn't covers deeply all 3 platforms. I did windows and mac parts.. and linux made by Javier.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 14 May 2013 00:45, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 May 2013 00:04, kilon <thekilon@yahoo.co.uk> wrote:
Ok so I tried to learn Opengl ES 2 (and opengl 4) during my eastern vacations because I realised
that I dont really need Athens or vector graphics for my GUI , since I will be dealing mostly with 3d graphics anyway. (My project "ephestos" will be an effort of creating a 3d app for pharo, see also "blender")
well, Athens provides convenient API for 2d vector graphics, which not exists in opengl .. One day i want to begin implementing opengl backend for Athens.
So when I tried to run the demos i get an error with
NBMacGLContextDriver>>supportsCurrentPlatform "obviously, for Mac intel-32 only :)" ^ NativeBoost platformId = NativeBoostConstants mac32PlaformId
My mac is "obviously" not 32-bit but 64 bit, but I dont know if that matters since pharo is only 32 bit anyway. The bug is also obvious it should be mac32PlatformId and not mac32PlaformId.
I correct and proceed and gives me a new error this time in
NBMacGlApi>>glApiCall: fnSpec index: fnIndex attributes: attributes context: contextToRetry
^[ (NBCallFailureHandler for: contextToRetry) retryWith: [ :targetClass :targetMethod | (NBFFICallout targetClass: targetClass targetMethod: targetMethod fnSpec: fnSpec) stdcall; generate: [ :gen | self emitCall: fnIndex generator: gen ] ] ] on: NBNativeCodeError do: [:err :handler | err errorCode = ErrorFnNotAvailable ifTrue: [ "Native code is installed, but function pointer not loaded yet. Try to load function and retry the call" (self tryGetFunctionPointer: (self class glFunctions at: fnIndex)) ifFalse: [ ^ err pass ]. ^ handler retrySend ]. err pass ]
The problem here that NBCallFailureHandler is nowhere to be found. At first I though my NB was lagging behind in version so I download from smalltalk Hub and did
ConfigurationOfNativeboost loadStable.
Neither my image has "NBCallFailureHandler". Looks like you loaded wrong version of NBOpenGL. How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
it should work out of the box. (and you don't need to load NativeBoost, because it is already in image).
it updated without errors but still that class is nowhere to be found.
So my question is this, does it really worth it to struggle with NBOpengl or will it better to learn how Nativeboost works and use Opengl myself ?
That what exactly NBOpenGL is. Its contents is bindings to OpenGL library (over 3000 functions) the rest is glue code , which mostly serves as an example how to create and initialize opengl context depending on platform you using.
The subcategory "NBOpenGL-Display" contains root classes with that glue code. While NBOpenGL-Core is 99% is just plain opengl api.
If you don't like this glue, you can just avoid using it.. but throwing away opengl core and making own.. makes little sense. I actually encouraged people to write better glue code for initializing context.. The main problem is that its highly platform specific.. and my knowledge doesn't covers deeply all 3 platforms. I did windows and mac parts.. and linux made by Javier.
Oh, and i should also mention, since depending on application you may want to initialize context differently (different pixel format , different number of buffers etc).. you will need to override/rewrite context initialization part by youself. So, the existing context initialization code is more for demo purposes but not for serious use. Another thing, that i don't see how i can provide sufficient "generic" context creation part, because there's a lot of flags and options which sometimes need fine tuning (like selecting most matching pixel format), which would make code too clever, and therefore rigid.. and i know by myself that it is best to be left for developer to decide what he wants and how.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua@gmail.com> wrote:
How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make ConfigurationOfNBOpenGL load. work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about. Esteban
I usually add a nice class comment in the configurationof... On May 15, 2013, at 9:37 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua@gmail.com> wrote:
How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make
ConfigurationOfNBOpenGL load.
work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about.
Esteban
On 15 May 2013 09:37, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua@gmail.com> wrote:
How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make
ConfigurationOfNBOpenGL load.
unless you put a lot of complex logic behind that "load", it will never work. That's why i prefer to giving a version numbers. This version of config works with 2.0 image, and no pain, no surprises. Now, when people get used to do "ConfigurationOfNBOpenGL load" it is less pain, but just for the next major update of whatever infrastructural parts in Pharo. And second, for me, as developer , it is much more helpful to deal with problem reports like: "this version doesn't loads/works with this version of image" instead of "i tried and it doesn't works" :)
work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about.
Esteban
-- Best regards, Igor Stasenko.
On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 May 2013 09:37, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua@gmail.com> wrote:
How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make
ConfigurationOfNBOpenGL load.
unless you put a lot of complex logic behind that "load", it will never work.
Why? load should be ConfigurationOfNBOpenGL class>>#load ^ self project stableVersion load. and nothing else
That's why i prefer to giving a version numbers. This version of config works with 2.0 image, and no pain, no surprises. Now, when people get used to do "ConfigurationOfNBOpenGL load" it is less pain, but just for the next major update of whatever infrastructural parts in Pharo.
again... why? Because what happens now is that people try to do what is the convention for metacello. Also, that means that by not following the conventions, NBOpenGL will never be able to be loaded through configuration browser :(
And second, for me, as developer , it is much more helpful to deal with problem reports like: "this version doesn't loads/works with this version of image" instead of "i tried and it doesn't works" :)
he, I'm sorry, I disagree... If you as a developer promote a version as a release by assigning a #stable symbolic version to configuration, you know exactly which version the guy is trying to load. And you will not have the problem "this version does not loads...", which is a consequence of not declaring a version as stable for a platform. Looks to me that the problem you try to avoid is in fact happening because the configuration is not adapted to the convention, not the opposite :) As proof... lot's of complex project follow the convention (seaside, for example), and nobody has the issue you say. Recently they prepared the configuration for 2.0, and that means that seaside now loads fine in 1.4 and 2.0.... cheers, Esteban
work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about.
Esteban
-- Best regards, Igor Stasenko.
Thank you all for your replies. I have used the solution I get new errors now. Is there an example how to create a context with NBOpenGL because the examples NBOpenGL is coming with are confusing at best ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4688138.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 17 May 2013 10:21, kilon <thekilon@yahoo.co.uk> wrote:
Thank you all for your replies. I have used the solution I get new errors now. Is there an example how to create a context with NBOpenGL because the examples NBOpenGL is coming with are confusing at best ?
Pharo2.0 Latest update: #20590 (ConfigurationOfNBOpenGL project version: '2.0') load GLTTRenderingDemo new openInWorld (works well.. no errors whatsoever) See a superclass (GLViewportMorph). The context created using: display := NBGLDisplay extent: self extent. To get access to OpenGL API (a subinstance of NBOpenGL) just use: display gl. The actual class, responsible for creating OpenGL context is one of NBGLContextDriver subclasses, since it is highly platform-specific. driver := NBGLContextDriver createContext: 100@100. gl := driver gl. The display (NBGLDisplay) wraps around driver and has some initialization to set up defaults and resource management to make sure resources released when it garbage collected (the driver does not, and you must free it explicitly). To use GL API , just send #gl message to either display or driver: drawCube | gl | gl := display gl. gl translatef_x: -1.5 y: 0 z: -60. gl rotatef_angle: rotationAngle x: 0 y: 1 z: 0. gl begin: GL_TRIANGLES; ... end. Please note, that in NBGLContextDriver(s) i hardcoded many things like pixel format, and NBOffscreenDisplay rendering into offscreen buffer etc. That means, if you want to create own initializer, i would start from making own driver. Sorry but the stuff there is highly platform specific. Making a generic driver which would accept some initialization options (like pixel format, number of buffers etc) while freeing user from platform-specific horrors is something which could be done in future. But as i said before, the devil is always in details , and i would just leave this to application developer. P.S. If , by chance, you wanna make things less confusing and more obvious, feel free to contribute to the project, i can add you as developer. You can change/improve anything. I only asking to keep GLTTRenderingDemo working :)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4688138.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Update the jenkins job to be multi-platform (though only loading #last): https://ci.inria.fr/pharo-contribution/job/NBOpenGL On 2013-05-17, at 09:10, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 May 2013 09:37, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua@gmail.com> wrote:
How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make
ConfigurationOfNBOpenGL load.
unless you put a lot of complex logic behind that "load", it will never work.
Why? load should be
ConfigurationOfNBOpenGL class>>#load ^ self project stableVersion load.
and nothing else
That's why i prefer to giving a version numbers. This version of config works with 2.0 image, and no pain, no surprises. Now, when people get used to do "ConfigurationOfNBOpenGL load" it is less pain, but just for the next major update of whatever infrastructural parts in Pharo.
again... why? Because what happens now is that people try to do what is the convention for metacello. Also, that means that by not following the conventions, NBOpenGL will never be able to be loaded through configuration browser :(
And second, for me, as developer , it is much more helpful to deal with problem reports like: "this version doesn't loads/works with this version of image" instead of "i tried and it doesn't works" :)
he, I'm sorry, I disagree... If you as a developer promote a version as a release by assigning a #stable symbolic version to configuration, you know exactly which version the guy is trying to load. And you will not have the problem "this version does not loads...", which is a consequence of not declaring a version as stable for a platform. Looks to me that the problem you try to avoid is in fact happening because the configuration is not adapted to the convention, not the opposite :) As proof... lot's of complex project follow the convention (seaside, for example), and nobody has the issue you say. Recently they prepared the configuration for 2.0, and that means that seaside now loads fine in 1.4 and 2.0....
cheers, Esteban
work out of the box, and also to copy them to MetaRepoForPharo20... so everybody can load without needing to thing a lot about.
Esteban
-- Best regards, Igor Stasenko.
On 17 May 2013 09:10, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 May 2013 09:37, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua@gmail.com> wrote:
How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make
ConfigurationOfNBOpenGL load.
unless you put a lot of complex logic behind that "load", it will never work.
Why? load should be
ConfigurationOfNBOpenGL class>>#load ^ self project stableVersion load.
and nothing else
the problem is that #stableVersion for 2.0 and #stableVersion for 1.4 may differ as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have it by default.
That's why i prefer to giving a version numbers. This version of config works with 2.0 image, and no pain, no surprises. Now, when people get used to do "ConfigurationOfNBOpenGL load" it is less pain, but just for the next major update of whatever infrastructural parts in Pharo.
again... why? Because what happens now is that people try to do what is the convention for metacello. Also, that means that by not following the conventions, NBOpenGL will never be able to be loaded through configuration browser :(
hmm, why i cannot specify in config browser that for given version of image use this version of library?
And second, for me, as developer , it is much more helpful to deal with problem reports like: "this version doesn't loads/works with this version of image" instead of "i tried and it doesn't works" :)
he, I'm sorry, I disagree... If you as a developer promote a version as a release by assigning a #stable symbolic version to configuration, you know exactly which version the guy is trying to load. And you will not have the problem "this version does not loads...", which is a consequence of not declaring a version as stable for a platform. Looks to me that the problem you try to avoid is in fact happening because the configuration is not adapted to the convention, not the opposite :) As proof... lot's of complex project follow the convention (seaside, for example), and nobody has the issue you say. Recently they prepared the configuration for 2.0, and that means that seaside now loads fine in 1.4 and 2.0....
Okay, then i will ask you to help making it working for 2.0 an 3.0 (we can ignore 1.4 i think). And here again, how you propose to deal with situation that i wanna discontinue support for 1.4 (so , if you do just #load, in 1.4 image it won't work, because latest #stable version does not supports that version of Pharo anymore).. Now if you specify exact version which still supports 1.4 you can load and use it. So, what is your recipe for this situation? Writing case statements? MyConfig>>stableVersion Smalltalk version = 1.4 ifTrue: [ ^ '0.4' ]. Smalltalk version = 2.0 ifTrue: [ ^ '0.8' ]. Smalltalk version = 3.0 ifTrue: [ ^ '1.8' ]. i can do that, if you insist.. but that IMO, defeats purpose of using Metacello. Because once you start with adding ugly if/case statements, they will tend to grow larger and larger over time.. and we end up with something like linux configure scripts..
cheers, Esteban
-- Best regards, Igor Stasenko.
On 2013-05-17, at 20:48, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 May 2013 09:10, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 May 2013 09:37, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua@gmail.com> wrote:
How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make
ConfigurationOfNBOpenGL load.
unless you put a lot of complex logic behind that "load", it will never work.
Why? load should be
ConfigurationOfNBOpenGL class>>#load ^ self project stableVersion load.
and nothing else
the problem is that #stableVersion for 2.0 and #stableVersion for 1.4 may differ as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have it by default.
you can easily do that: stable: spec <symbolicVersion: #stable > spec for: #'pharo1.4' version: '100'. spec for: #'pharo2.0' version: '200'. spec for: #'pharo3.0' version: '300'.
On 17 May 2013 20:56, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-17, at 20:48, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 May 2013 09:10, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 16, 2013, at 11:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 15 May 2013 09:37, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On May 14, 2013, at 12:45 AM, Igor Stasenko <siguctua@gmail.com> wrote:
How did you loaded NBOpenGL? For 2.0/3.0 pharo image use (ConfigurationOfNBOpenGL project version: '2.0') load
I added this important piece of information into http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :) It would be a lot better to make
ConfigurationOfNBOpenGL load.
unless you put a lot of complex logic behind that "load", it will never work.
Why? load should be
ConfigurationOfNBOpenGL class>>#load ^ self project stableVersion load.
and nothing else
the problem is that #stableVersion for 2.0 and #stableVersion for 1.4 may differ as well as dependencies.. in 1.4 there is no NB loaded, while 2.0 have it by default.
you can easily do that:
stable: spec <symbolicVersion: #stable >
spec for: #'pharo1.4' version: '100'. spec for: #'pharo2.0' version: '200'. spec for: #'pharo3.0' version: '300'.
thanks. (it is still a case statement, but not so ugly however ;)
-- Best regards, Igor Stasenko.
Hey Igor , yes I would love to contrinbute to NBOpenGL for a very long time. I could at least fix those small errors like the one I reported and add documentation to methods and especially classes. I am using pharo 3.0 and GLTTRenderingDemo does not work. I get an error. Apparently it cannot find ShortPointArray which is initialised inside TTCountourConstruction>>asCompressedPoints I remember having same issues with pharo 2.0 too. I am also confused how to use NBGLCurveRenderer. Thank you for your detailed explanation I have tried GLViewportMorphic I see no errors , so its should work fine. I am new to opengl myself , and smalltalk and nativeboost so I try to understand as much I can before doing actual coding and I feel I am at that stage that I can do and I would love to contribute my work back to pharo because I plan to implement at least a basic 3d engine and very basic MoprhicGL GUI. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689207.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I am looking at NBGLContextDriver and NBGLDisplay and I see none of that hard coded stuff. I assume you mean the platform specific packages like NBMacGLContextDriver ,NBGLXContextDriver etc. where I see alot of platform specific code inside the methods of those classes . -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689211.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 22 May 2013 20:11, kilon <thekilon@yahoo.co.uk> wrote:
I am looking at NBGLContextDriver and NBGLDisplay and I see none of that hard coded stuff.
Look more carefully: there's a code to manage viewport and setting up buffers and other things, like blend more etc in those classes. It is not platform-specific (because it uses purely only opengl api), but it doesn't makes it less hardcoded.
I assume you mean the platform specific packages like NBMacGLContextDriver ,NBGLXContextDriver etc. where I see alot of platform specific code inside the methods of those classes .
Yes, it has to be platform-specific. But do not confuse "hardcoded" stuff with "platform-specific" code. Ideally, there should be no hardcoded one, but it is hard to achieve (for the reasons i mentioned before, and one of them is platform-specificness, of course).
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689211.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 22 May 2013 20:00, kilon <thekilon@yahoo.co.uk> wrote:
Hey Igor , yes I would love to contrinbute to NBOpenGL for a very long time. I could at least fix those small errors like the one I reported and add documentation to methods and especially classes.
I am using pharo 3.0 and GLTTRenderingDemo does not work. I get an error.
Apparently it cannot find ShortPointArray which is initialised inside TTCountourConstruction>>asCompressedPoints
Okay, seems like this class got removed. (i think i remember seeing issue abound it)... I already saved some classes which was thrown out of Pharo image into separate package (like code to read and decypher .tff files). But changes keep going.. (what a surprise ;) and so require energy and time to keep things up to date.
I remember having same issues with pharo 2.0 too.
I am also confused how to use NBGLCurveRenderer.
you don't. i made this class purely for my demo purposes. the code there is far-far from general use. :)
Thank you for your detailed explanation I have tried GLViewportMorphic I see no errors , so its should work fine.
I am new to opengl myself , and smalltalk and nativeboost so I try to understand as much I can before doing actual coding and I feel I am at that stage that I can do and I would love to contribute my work back to pharo because I plan to implement at least a basic 3d engine and very basic MoprhicGL GUI.
so, if you able to instantiate GLViewport and open it in window, try to render something (simple triangles etc..) and see if you get anything.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689207.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
I added you as contributor to project. Feel free to contribute! :) I would love to play more with OpenGL, but i am swamped with other stuff. -- Best regards, Igor Stasenko.
ok i see, well I did not mean that we dont need platform specific code, of course we do. thanks for adding me. I will first try to contribute some example classes that show how nbopengl can be used in practice. And see if I can fix any of the bugs I find. No problem if you dont have time, I do and will HOPEFULLY be the very area will focus from now , so I am here to stay unless I hit a dead end and cant use opengl properly for some reason. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4689853.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Ok new problem, NBOpengl seems to not work at all on my UBUNTU 12.10 machine. I was trying to do GLViewportMorph new openInWorld , which works fine on my iMac and it gave me error: function unavailable. So I assumed it cannot find some dynamic library , so I checked around the code and found that in package NBXLib-Core NBXlibHandle>>nbLibraryNameOrHandle class method, it returns '/usr/lib/libX11.so'. However browsing through the directories its clear that the library is not located in there but rather is located as a symlink in a) /usr/lib/i386-linux-gnu b) /usr/lib/x86_64-linux-gnu. Both symlink point to libx11.so.6.3.0 libraries. So knowning that pharo is 32 bit I went for option (a) however still it gives me the same error. Any idea what it may be ? Another question I have is does it not NB check first to see if the library is available ? Because it looks weird that it complains about non existent functions but does not complain about non existent library. Here is the stack NBFFICallout(Object)>>error: NBFFICallout>>generateCall:module: NBGlxAPI>>call: in Block: [...] NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: in Block: [...] BlockClosure>>on:do: NBRecursionDetect class>>in:during: NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: NBGlxAPI>>call: NBGlxAPI>>queryExtension:errorBase:eventBase: NBGLXContextDriver>>createContext: NBGLContextDriver class>>createContext: NBGLDisplay class>>extent: GLViewportMorph>>initializeForNewSession GLViewportMorph>>initialize GLViewportMorph class(Behavior)>>new UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: SmalltalkEditor>>evaluateSelectionAndDo: SmalltalkEditor>>evaluateSelection PluggableTextMorph>>doIt in Block: [...] PluggableTextMorph>>handleEdit: in Block: [...] TextMorphForEditView(TextMorph)>>handleEdit: PluggableTextMorph>>handleEdit: PluggableTextMorph>>doIt Workspace(Object)>>perform:orSendTo: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [...] BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4691549.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 4 June 2013 11:40, kilon <thekilon@yahoo.co.uk> wrote:
Ok new problem, NBOpengl seems to not work at all on my UBUNTU 12.10 machine. I was trying to do GLViewportMorph new openInWorld , which works fine on my iMac and it gave me error: function unavailable.
So I assumed it cannot find some dynamic library , so I checked around the code and found that in package NBXLib-Core NBXlibHandle>>nbLibraryNameOrHandle class method, it returns '/usr/lib/libX11.so'. However browsing through the directories its clear that the library is not located in there but rather is located as a symlink in a) /usr/lib/i386-linux-gnu b) /usr/lib/x86_64-linux-gnu. Both symlink point to libx11.so.6.3.0 libraries.
So knowning that pharo is 32 bit I went for option (a) however still it gives me the same error.
Any idea what it may be ?
Another question I have is does it not NB check first to see if the library is available ? Because it looks weird that it complains about non existent functions but does not complain about non existent library.
NB uses a VM API to look for a function in library. That function provides no error feedback (just success or not). and also, it combines with loading library as well. So it is hard to say what exactly happened: did library failed to load or library loaded fine, but function not found. (see #loadSymbol:fromModule: implementation) To put an end to endless mystery, i propose you to implement a small diagnostic tool.. There is not much to do: - call dlopen() - if it fails, call dlerror() , and get details about failure. - call dlsym - if it fails, call dlerror() , and get details about failure.
Here is the stack
NBFFICallout(Object)>>error: NBFFICallout>>generateCall:module: NBGlxAPI>>call: in Block: [...] NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: in Block: [...] BlockClosure>>on:do: NBRecursionDetect class>>in:during: NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: NBGlxAPI>>call: NBGlxAPI>>queryExtension:errorBase:eventBase: NBGLXContextDriver>>createContext: NBGLContextDriver class>>createContext: NBGLDisplay class>>extent: GLViewportMorph>>initializeForNewSession GLViewportMorph>>initialize GLViewportMorph class(Behavior)>>new UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: SmalltalkEditor>>evaluateSelectionAndDo: SmalltalkEditor>>evaluateSelection PluggableTextMorph>>doIt in Block: [...] PluggableTextMorph>>handleEdit: in Block: [...] TextMorphForEditView(TextMorph)>>handleEdit: PluggableTextMorph>>handleEdit: PluggableTextMorph>>doIt Workspace(Object)>>perform:orSendTo: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [...] BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4691549.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Ok I am moving towards the direction you indicated , its just takes time because I am clueless. Af far as macos is concerned I was sucessful into intialising opengl context following your instructions and using clearColor assigned green-blue background to it. Works like a charm even changing the code updates the window to the corresponding color, live coding in all its glory. I am having tons of fun with it. I have a strange bug , well it seems that opengl looses a connection with memory and i have to reinitialize my GLTutorial1 class and pops a framebuffer error. It does it only after some time passes and pharo is idle, its a strange bug, but if it starts appearing again I will try to pin point it, because my code is not up to the opengl standards yet so it may be me that cause this issue. My problem right now is that I follow the tutorial at arcsynth and I am stuck here http://www.arcsynthesis.org/gltut/Basics/Tut01%20Following%20the%20Data.html <http://www.arcsynthesis.org/gltut/Basics/Tut01%20Following%20the%20Data.html> glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW); the question is how i find the size in smalltalk . There is bufferData_target: size: data: usage: which corresponds to that function but I have no idea how to convert sizeof() to smalltalk. Any clues ? If you want to see my code I have commited it in NBOpengl smalltalkhub the latest is NBOpenGL-Morphic-kilon.10 for NBOpenGL-Morphic. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4692494.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 9 June 2013 20:47, kilon <thekilon@yahoo.co.uk> wrote:
Ok I am moving towards the direction you indicated , its just takes time because I am clueless.
Af far as macos is concerned I was sucessful into intialising opengl context following your instructions and using clearColor assigned green-blue background to it. Works like a charm even changing the code updates the window to the corresponding color, live coding in all its glory. I am having tons of fun with it.
I have a strange bug , well it seems that opengl looses a connection with memory and i have to reinitialize my GLTutorial1 class and pops a framebuffer error. It does it only after some time passes and pharo is idle, its a strange bug, but if it starts appearing again I will try to pin point it, because my code is not up to the opengl standards yet so it may be me that cause this issue.
My problem right now is that I follow the tutorial at arcsynth and I am stuck here
http://www.arcsynthesis.org/gltut/Basics/Tut01%20Following%20the%20Data.html <http://www.arcsynthesis.org/gltut/Basics/Tut01%20Following%20the%20Data.html>
glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW);
the question is how i find the size in smalltalk . There is bufferData_target: size: data: usage: which corresponds to that function but I have no idea how to convert sizeof() to smalltalk. Any clues ?
Yes. (NBExternalType sizeOf: 'float') * number of floats in your buffer or (NBExternalType sizeOf: 'double') * number of floats in your buffer For arrays of static type, i would recommend you using NBExternalArray, which gives you a convenient way to deal with arrays of any static type in smalltalk way. For passing it as argument to function you can use 'array address' idiom. See class comments for details. Btw, getting the size of array, in bytes, would be: sizeInBytes ^ self size * self class elementSize (i think this method would be nice to have).
If you want to see my code I have commited it in NBOpengl smalltalkhub the latest is NBOpenGL-Morphic-kilon.10 for NBOpenGL-Morphic.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4692494.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On 10 June 2013 03:54, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 June 2013 20:47, kilon <thekilon@yahoo.co.uk> wrote:
Ok I am moving towards the direction you indicated , its just takes time because I am clueless.
Af far as macos is concerned I was sucessful into intialising opengl context following your instructions and using clearColor assigned green-blue background to it. Works like a charm even changing the code updates the window to the corresponding color, live coding in all its glory. I am having tons of fun with it.
I have a strange bug , well it seems that opengl looses a connection with memory and i have to reinitialize my GLTutorial1 class and pops a framebuffer error. It does it only after some time passes and pharo is idle, its a strange bug, but if it starts appearing again I will try to pin point it, because my code is not up to the opengl standards yet so it may be me that cause this issue.
Sorry, did not replied to this part. Yes, i found strange behavior as well: it creates context every 2nd time, and giving error in between. There could be some wrong code in handling the context.. (it also can be related to GC, because context is not destroyed directly in my demo, but released by finalization)
My problem right now is that I follow the tutorial at arcsynth and I am stuck here
http://www.arcsynthesis.org/gltut/Basics/Tut01%20Following%20the%20Data.html <http://www.arcsynthesis.org/gltut/Basics/Tut01%20Following%20the%20Data.html>
glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW);
the question is how i find the size in smalltalk . There is bufferData_target: size: data: usage: which corresponds to that function but I have no idea how to convert sizeof() to smalltalk. Any clues ?
Yes.
(NBExternalType sizeOf: 'float') * number of floats in your buffer
or
(NBExternalType sizeOf: 'double') * number of floats in your buffer
For arrays of static type, i would recommend you using NBExternalArray, which gives you a convenient way to deal with arrays of any static type in smalltalk way. For passing it as argument to function you can use 'array address' idiom. See class comments for details.
Btw, getting the size of array, in bytes, would be:
sizeInBytes ^ self size * self class elementSize
(i think this method would be nice to have).
If you want to see my code I have commited it in NBOpengl smalltalkhub the latest is NBOpenGL-Morphic-kilon.10 for NBOpenGL-Morphic.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4692494.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
I am trying to find out what version of Opengl NBOpenGL is using so I do: gl getString:GL_VERSION. it works and returns me a pointer. I looked at definition of methods and it is defined to return a pointer. Question is how I get the string that the pointer points too ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694552.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Have you tried (gl getString: GL_VERSION) readString or if it does not return an NBExternalAddress (NBExternalAddress value: (gl getString: GL_VERSION)) readstring On Sat, Jun 22, 2013 at 4:46 PM, kilon <thekilon@yahoo.co.uk> wrote:
I am trying to find out what version of Opengl NBOpenGL is using so I do:
gl getString:GL_VERSION.
it works and returns me a pointer. I looked at definition of methods and it is defined to return a pointer.
Question is how I get the string that the pointer points too ?
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694552.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
No I did not, because I dont have the brain power to assume that NBExternalAdress will have some methods to make my life easier. And of course it works like a charm now, thank you very much :) -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694639.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
next question . I have this method. initializeProgram "create each shader and program" | shaderList strVertexShader strFragmentShader | strVertexShader := self createShader: GL_VERTEX_SHADER string: ( self vertexShader ). strFragmentShader := self createShader: GL_FRAGMENT_SHADER string: (self fragmentShader) . shaderList := #( strVertexShader strFragmentShader ). self createProgram: shaderList . shaderList do: [ :each | gl deleteShader: each ]. Each time I try to accept the code it complains that strVertexShader and strFragmentShader are unused and ask for removing them . Why ? Is this an IDE bug ? Its clear from the code that I use those two local variables to pass them to the array shaderList. Am I missing something here ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694650.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Jun 23, 2013, at 4:52 PM, kilon <thekilon@yahoo.co.uk> wrote:
next question .
I have this method.
initializeProgram "create each shader and program"
| shaderList strVertexShader strFragmentShader |
strVertexShader := self createShader: GL_VERTEX_SHADER string: ( self vertexShader ). strFragmentShader := self createShader: GL_FRAGMENT_SHADER string: (self fragmentShader) . shaderList := #( strVertexShader strFragmentShader ). self createProgram: shaderList . shaderList do: [ :each | gl deleteShader: each ].
Each time I try to accept the code it complains that strVertexShader and strFragmentShader are unused and ask for removing them . Why ?
Is this an IDE bug ? Its clear from the code that I use those two local variables to pass them to the array shaderList. Am I missing something here ?
Yes: shaderList := #( strVertexShader strFragmentShader ). here the Array you create is a so called literal Array. It can not contain variables, only literals. The compiler sees is as #(#strVertexShader #strFragmentShader). What you need instead is a compile time evaluated Array: shaderList := {strVertexShader strFragmentShader}. Marcus
yeah and I read about that in PBE and of course I forgot about it. That is why we need the mailing lists. Ok that solved the problem partially it does not complain about strVertexShader but it still complains about strFragmentShader . I use this code. shaderList := {strVertexShader strFragmentShader}. Any idea what may still be wrong ? "strFragmentShader appears to be unused in this method. Ok to remove it ?" -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694685.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Jun 23, 2013, at 5:51 PM, kilon <thekilon@yahoo.co.uk> wrote:
yeah and I read about that in PBE and of course I forgot about it. That is why we need the mailing lists.
Ok that solved the problem partially it does not complain about strVertexShader but it still complains about strFragmentShader . I use this code.
shaderList := {strVertexShader strFragmentShader}.
Any idea what may still be wrong ?
There needs to be a dot: shaderList := {strVertexShader . strFragmentShader}. (I guess I forgot to put it in my example)
"strFragmentShader appears to be unused in this method. Ok to remove it ?"
thank you , it works now. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4694696.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
My code gl shaderSource_shader: shader count: 1 string: shaderString length: 0. must not be correct. I try to translate this glShaderSource(shader, 1, &strFileData, NULL); using the tutorial in here -> http://www.arcsynthesis.org/gltut/Basics/Tut01%20Making%20Shaders.html <http://www.arcsynthesis.org/gltut/Basics/Tut01%20Making%20Shaders.html> I made these assumptions here a) Nativeboost would take my string shaderString and pass its address to glShaderSource() b) that NB would automagically convert 0 to NULL are these assumptions correct and if yes why I am getting an "error during FFI call: NIL" if no, how I can pass the address of the string and how may I pass NULL as well ? as always you can get my code manually from the NBOpengl repo in smalltalk hub to take a look at the whole code. I have not added my code to ConfigurationOfNBOpenGL cause it does not work yet and its a WIP. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695217.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I also tried gl shaderSource_shader: shader count: 1 string: (NBExternalAddress fromString: shaderString) length: (NBExternalObject null) . still getting "Error during FFI call : NIL" . This is the full method : createShader: shaderType string: shaderString " create shader using its source and compile it , return shader" | shader | shader := gl createShader: shaderType . gl shaderSource_shader: shader count: 1 string: (NBExternalAddress fromString: shaderString) length: (NBExternalObject null) . gl compileShader: shader. ^ shader . I also use gl getError to get any possible opengl error in my part , It reports that there is no such error.I am continuing investigating Nativeboost -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695575.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
According to the 2.1 reference in opengl website http://www.opengl.org/sdk/docs/man2/ <http://www.opengl.org/sdk/docs/man2/> glShaderSource I have to pass an array of pointers that point to the strings that make the shader's source. Question is does NBExternalAdress fromString: shaderString , does that ? If no, how I create an array of pointers from a single string ? It looks like that the call itself fails because nativeboost does not like how I call the function, so that explains why I get no opengl error. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695614.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 27 June 2013 10:30, kilon <thekilon@yahoo.co.uk> wrote:
I also tried
gl shaderSource_shader: shader count: 1 string: (NBExternalAddress fromString: shaderString) length: (NBExternalObject null) .
still getting "Error during FFI call : NIL" .
This is the full method :
createShader: shaderType string: shaderString " create shader using its source and compile it , return shader"
| shader | shader := gl createShader: shaderType . gl shaderSource_shader: shader count: 1 string: (NBExternalAddress fromString: shaderString) length: (NBExternalObject null) . gl compileShader: shader. ^ shader
i think it fails because you passing strange (NBExternalObject null) as length parameter. i guess you meant NBExternalAddress null instead. here the function prototype: void glShaderSource ( GLuint shader , GLsizei count , GLchar** string , long* length ) so, length and string is both pointers, and NB marshalling knows only that (it doesn't knows if there are arrays of strings, ints or whatever). So, to make it happy you must pass instances of NBExternalAddress as both of there parameters. And code will look like: assume that you have an array of strings, holding the shader sources, lets call it sources. sources := #( ' this is first' 'this is second' 'etc' ). sizeOfPointer := NBExternalType sizeOf: 'void*'. "allocate buffer for array of pointers" externalArrayOfPointers := NativeBoost allocate: sizeOfPointer * sources size. "allocate strings and copy them to external heap" sourcesOnHeap := sources collect: [:each | NBExternalAddress fromString: each ]. "copy string pointers to external array" sourcesOnHeap withIndexDo: [:ptr :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " externalArrayOfPointers nbUInt32AtOffset: (i-1)*4 put: ptr value ] and now you can call that function gl shaderSource_shader: shader count: sources size string: externalArrayOfPointers length: (NBExternalAddress null) . but after, don't forget to free the memory: sourcesOnHeap do: [:each | each free]. externalArrayOfPointers free.
. I also use gl getError to get any possible opengl error in my part , It reports that there is no such error.I am continuing investigating Nativeboost
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695575.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On Jun 27, 2013, at 2:22 , Igor Stasenko wrote:
i think it fails because you passing strange (NBExternalObject null) as length parameter. i guess you meant NBExternalAddress null instead.
Speaking of weird external stuff⦠NBExternalArray class >> #initElementType: aTypeName "Initialize the element type and size. If you want to use a public subclass of me, then make sure you call this method in your class #initialize method. " elementType := aTypeName. elementSize := (NBFFICallout new requestor: self; resolveType: elementType) valueSize . self installAccessors. Shouldn't that be storageSize? Or is a disclaimer not to use the class for, say, 'char*' elements more appropriate? Cheers, Henry
On 27 June 2013 15:34, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Jun 27, 2013, at 2:22 , Igor Stasenko wrote:
i think it fails because you passing strange (NBExternalObject null) as length parameter. i guess you meant NBExternalAddress null instead.
Speaking of weird external stuffâ¦
NBExternalArray class >> #initElementType: aTypeName "Initialize the element type and size. If you want to use a public subclass of me, then make sure you call this method in your class #initialize method. "
elementType := aTypeName. elementSize := (NBFFICallout new requestor: self; resolveType: elementType) valueSize . self installAccessors.
Shouldn't that be storageSize?
Yes, you right. (NBFFICallout new resolveType: 'byte*') valueSize => 1 (NBFFICallout new resolveType: 'byte*') storageSize => 4 apparently, if one wants array with 'byte*' element type (or any other) it should use a pointer size (4), not byte size (1) for it.
Or is a disclaimer not to use the class for, say, 'char*' elements more appropriate?
no , it should be fine. The difference between valueSize and storageSize is a bit confusing, and easy to confuse which to use.. Perhaps they need different naming. There also stackSize, which means "how many bytes a value of given type will take, if pushed on stack , and aligned accordingly" ... after some more investigation, i found that actually storageSize should not be used. There is typeSize instead. So, the final expression should be: elementType := aTypeName. elementSize := (NBFFICallout new requestor: self; resolveType: elementType) typeSize. and #sizeOf: method should also use typeSize apparently.
Cheers, Henry
-- Best regards, Igor Stasenko.
On Jun 27, 2013, at 4:11 , Igor Stasenko wrote:
Or is a disclaimer not to use the class for, say, 'char*' elements more appropriate?
no , it should be fine.
Was thinking of that in conjunction with putting ST object refs in the External arrays, the trying to pass as parameters, it could be a recipe for disaster :) Like, say: "Add a null at end so ExternalArrays basic #readString won't keep on readin'" string := 'Hello world!' copyWith: (Character value: 0). extArray := (NBExternalArray ofType: 'char*') new: 1. "Tenure the string first, lest we invalidate on next scavenge" Smalltalk garbageCollectMost. extArray at:1 put: string. "X our fingers, and hope GC doesn't move string. Often serves as a nice example that it will :)" (extArray at: 1) readString string at: 7 put: $W. (extArray at: 1) readString Cheers, Henry
On 27 June 2013 17:14, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Jun 27, 2013, at 4:11 , Igor Stasenko wrote:
Or is a disclaimer not to use the class for, say, 'char*' elements more appropriate?
no , it should be fine.
Was thinking of that in conjunction with putting ST object refs in the External arrays, the trying to pass as parameters, it could be a recipe for disaster :) Like, say:
"Add a null at end so ExternalArrays basic #readString won't keep on readin'" string := 'Hello world!' copyWith: (Character value: 0). extArray := (NBExternalArray ofType: 'char*') new: 1. "Tenure the string first, lest we invalidate on next scavenge" Smalltalk garbageCollectMost. extArray at:1 put: string.
"X our fingers, and hope GC doesn't move string. Often serves as a nice example that it will :)" (extArray at: 1) readString string at: 7 put: $W. (extArray at: 1) readString
hehe.. that certainly a recipe for disaster. That's why there should be no NBExternalValue>>address (pointing at Ciprian), which answers a pointer to oop's first byte, like that given test: testOutVoidArg |x value| NBTestExternalValue initialize. value := 12345678. x := NBTestExternalValue new. self outputVoidArg: x address value: value. self assert: x value = value. may work. But actually it will not. And this is **WRONG** in same way as your example.
Cheers, Henry
-- Best regards, Igor Stasenko.
Igor we should document such mistakes This is important can you add such comments in class comment? On Jun 27, 2013, at 5:26 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 27 June 2013 17:14, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Jun 27, 2013, at 4:11 , Igor Stasenko wrote:
Or is a disclaimer not to use the class for, say, 'char*' elements more appropriate?
no , it should be fine.
Was thinking of that in conjunction with putting ST object refs in the External arrays, the trying to pass as parameters, it could be a recipe for disaster :) Like, say:
"Add a null at end so ExternalArrays basic #readString won't keep on readin'" string := 'Hello world!' copyWith: (Character value: 0). extArray := (NBExternalArray ofType: 'char*') new: 1. "Tenure the string first, lest we invalidate on next scavenge" Smalltalk garbageCollectMost. extArray at:1 put: string.
"X our fingers, and hope GC doesn't move string. Often serves as a nice example that it will :)" (extArray at: 1) readString string at: 7 put: $W. (extArray at: 1) readString
hehe.. that certainly a recipe for disaster.
That's why there should be no NBExternalValue>>address (pointing at Ciprian), which answers a pointer to oop's first byte, like that given test:
testOutVoidArg |x value| NBTestExternalValue initialize. value := 12345678. x := NBTestExternalValue new.
self outputVoidArg: x address value: value.
self assert: x value = value.
may work. But actually it will not. And this is **WRONG** in same way as your example.
Cheers, Henry
-- Best regards, Igor Stasenko.
On 27 June 2013 18:33, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor we should document such mistakes This is important can you add such comments in class comment?
Well, it is a general rule to never operate with pointers to moveable objects, because objects may change their locations at any moment and you don't control that. A pointer to object can be considered non-moving only if: - there is no allocation(s) of new objects between obtaining the pointer value and using it (like passing to external function) - you not running any smalltalk code/function you call will NOT call back and enter smalltalk code - you cannot be interrupted by something, which would allow the above. in short, anything which may cause GC between point where you got the pointer and point where you going to use it is a recipe for disaster. -- Best regards, Igor Stasenko.
Ok we solved that problem lest move to the next one. I have this line of code Glint status; to be used in this glGetShaderiv(shader, GL_COMPILE_STATUS, &status); Now my first thought was to do this statusAdress := NativeBoost allocate: NBOpenGLTypes GLint. but of course NBOpenGLTypes GLint is not really a message so that fails. My problem here is that allocate , allocates a specific amount of bytes and then returns the address. The problem is that there is no gurantee how many bytes a GLint is. Is there a method somewhere in NBOpengl that can return me that amount of bytes of a GLint in the platform that NBOpengl executes ? Remember I cant use here a constant number cause there is no guarantees that GLint will be the same size for every user of NBOpengl. This is really fun by the way learning so low level stuff :) -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695790.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 27 June 2013 21:25, kilon <thekilon@yahoo.co.uk> wrote:
Ok we solved that problem lest move to the next one.
I have this line of code
Glint status;
to be used in this
glGetShaderiv(shader, GL_COMPILE_STATUS, &status);
Now my first thought was to do this
statusAdress := NativeBoost allocate: NBOpenGLTypes GLint.
but of course NBOpenGLTypes GLint is not really a message so that fails.
My problem here is that allocate , allocates a specific amount of bytes and then returns the address. The problem is that there is no gurantee how many bytes a GLint is. Is there a method somewhere in NBOpengl that can return me that amount of bytes of a GLint in the platform that NBOpengl executes ?
Remember I cant use here a constant number cause there is no guarantees that GLint will be the same size for every user of NBOpengl.
This is really fun by the way learning so low level stuff :)
Well, on 32-bit system GLInt is alias for int, int32 To check its size you can do something like following: (NBFFICallout new requestor: <put a class which has access to GLInt>; resolveType: 'GLInt') typeSize Try NBExternalType sizeOf: 'GLInt'
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695790.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Care to explain whats the difference between one from the other ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695864.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
found a bug in NBOpengl this function definition is incorrect getShaderiv_shader: "in" shader pname: "in" pname params: "out" params <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: primErrorCode> ^ self glApiCall: #( void glGetShaderiv ( GLuint shader , GLenum pname , long* params ) ) index: 793 attributes: #( #category #VERSION_2_0 #version #'2.0' ) while the function definition is void glGetShaderiv(GLuint shader, GLenum pname, GLint * params); so there is no long* in there for params as is confirmed from opengl 2.1 reference pages -> http://www.opengl.org/sdk/docs/man2/ <http://www.opengl.org/sdk/docs/man2/> dont know if this bug has any effect , or maybe not a bug ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695962.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 28 June 2013 13:11, kilon <thekilon@yahoo.co.uk> wrote:
found a bug in NBOpengl this function definition is incorrect
getShaderiv_shader: "in" shader pname: "in" pname params: "out" params <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: primErrorCode>
^ self glApiCall: #( void glGetShaderiv ( GLuint shader , GLenum pname , long* params ) ) index: 793 attributes: #( #category #VERSION_2_0 #version #'2.0' )
while the function definition is
void glGetShaderiv(GLuint shader, GLenum pname, GLint * params);
so there is no long* in there for params
as is confirmed from opengl 2.1 reference pages -> http://www.opengl.org/sdk/docs/man2/ <http://www.opengl.org/sdk/docs/man2/>
dont know if this bug has any effect , or maybe not a bug ?
Looks like a bug in openg specs. But it has no effect. Pointer to long, or pointer to GLInt.. it makes not difference, at least from side of FFI marshaller, because it just takes a pointer. Btw, they switches to XML specs, and old ones are no longer updated.. that means we should rebase bindings generator to read from XML data.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695962.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
I am not going to post my code here cause it has become too big , you can find it here http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial> I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 30 June 2013 21:11, kilon <thekilon@yahoo.co.uk> wrote:
I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source. So for our next challenge is learning how to fetch data that a pointer points to. in this case I have an array that contains my vertex positions , called vertexPositions vertexPositions "the positions of vertices to be passed to opengl" ^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 ) so far so good so I create a pointer for that array vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size. and then take that pointer and insert in each position the individual values from vertexPositions vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ]. so far so good. now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW. where you see the dots is where I should pass the data, in this case the C array I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array. So how I do that ? I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ? NBExternalAdress value , returns the number of the address and not that data contained in that address. I also see a NBExternalArray but I am not sure if it is what I should be using . Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
> wrote:
I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Sorry I forgot to paste how i create the vpos pointer vpos := NativeBoost allocate: vptrsize. My questions on how to pass the contents of a C array to a C function as can be seen in quoted message remains :) kilon wrote
Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source.
So for our next challenge is learning how to fetch data that a pointer points to.
in this case I have an array that contains my vertex positions , called vertexPositions
vertexPositions "the positions of vertices to be passed to opengl"
^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 )
so far so good
so I create a pointer for that array
vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size.
and then take that pointer and insert in each position the individual values from vertexPositions
vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ].
so far so good.
now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created
gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW.
where you see the dots is where I should pass the data, in this case the C array
I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array.
So how I do that ?
I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ?
NBExternalAdress value , returns the number of the address and not that data contained in that address.
I also see a NBExternalArray but I am not sure if it is what I should be using . Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
> wrote:
I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696667.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I love your questions! When you will get all your anwsers you have to write a blog about it so that we can use that in a chapter so that every body can know how to do it. Just no time to think right now :( sadly Stef On Jul 1, 2013, at 8:40 PM, kilon <thekilon@yahoo.co.uk> wrote:
Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source.
So for our next challenge is learning how to fetch data that a pointer points to.
in this case I have an array that contains my vertex positions , called vertexPositions
vertexPositions "the positions of vertices to be passed to opengl"
^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 )
so far so good
so I create a pointer for that array
vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size.
and then take that pointer and insert in each position the individual values from vertexPositions
vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ].
so far so good.
now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created
gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW.
where you see the dots is where I should pass the data, in this case the C array
I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array.
So how I do that ?
I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ?
NBExternalAdress value , returns the number of the address and not that data contained in that address.
I also see a NBExternalArray but I am not sure if it is what I should be using .
Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
> wrote:
I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
And I love pharo and what you guys have created , a lot of fun and very productive. So yes I will definitely help you out in documenting NB. Actually my idea was not to publish in a blog. I hate blogs though I have one I just find it very non flexible so I was thinking instead wikibooks . http://en.wikibooks.org/wiki/Help:Contributing <http://en.wikibooks.org/wiki/Help:Contributing> I was thinking moving the entire nativeboost docs (pdf/latex) to wiki books so I make it much easier for everyone can contribute. Wikibooks uses Mediawiki which I am familiar with from the blender wiki when I was making my python book http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic <http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic> Mediawiki is nowhere near as powerful as latex but its way easier to learn and it literally takes minutes to learn the syntax and you dont need a special editor you can do it online directly with minimum syntax. This way everyone can contribute , it only needs an account. Stéphane Ducasse wrote
I love your questions! When you will get all your anwsers you have to write a blog about it so that we can use that in a chapter so that every body can know how to do it.
Just no time to think right now :( sadly
Stef
On Jul 1, 2013, at 8:40 PM, kilon <
thekilon@.co
> wrote:
Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source.
So for our next challenge is learning how to fetch data that a pointer points to.
in this case I have an array that contains my vertex positions , called vertexPositions
vertexPositions "the positions of vertices to be passed to opengl"
^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 )
so far so good
so I create a pointer for that array
vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size.
and then take that pointer and insert in each position the individual values from vertexPositions
vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ].
so far so good.
now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created
gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW.
where you see the dots is where I should pass the data, in this case the C array
I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array.
So how I do that ?
I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ?
NBExternalAdress value , returns the number of the address and not that data contained in that address.
I also see a NBExternalArray but I am not sure if it is what I should be using .
Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
> wrote:
I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696807.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I like to see people contributing :), maybe you could do some contribution on the code-side? I personally consider well written, executable examples more valuable than written documentation outside the image. And I think NativeBoost could benefit from some in-image documentation. On 2013-07-02, at 14:39, kilon <thekilon@yahoo.co.uk> wrote:
And I love pharo and what you guys have created , a lot of fun and very productive. So yes I will definitely help you out in documenting NB.
Actually my idea was not to publish in a blog. I hate blogs though I have one I just find it very non flexible so I was thinking instead wikibooks .
http://en.wikibooks.org/wiki/Help:Contributing <http://en.wikibooks.org/wiki/Help:Contributing>
I was thinking moving the entire nativeboost docs (pdf/latex) to wiki books so I make it much easier for everyone can contribute. Wikibooks uses Mediawiki which I am familiar with from the blender wiki when I was making my python book
http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic <http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic>
Mediawiki is nowhere near as powerful as latex but its way easier to learn and it literally takes minutes to learn the syntax and you dont need a special editor you can do it online directly with minimum syntax. This way everyone can contribute , it only needs an account.
Stéphane Ducasse wrote
I love your questions! When you will get all your anwsers you have to write a blog about it so that we can use that in a chapter so that every body can know how to do it.
Just no time to think right now :( sadly
Stef
On Jul 1, 2013, at 8:40 PM, kilon <
thekilon@.co
> wrote:
Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source.
So for our next challenge is learning how to fetch data that a pointer points to.
in this case I have an array that contains my vertex positions , called vertexPositions
vertexPositions "the positions of vertices to be passed to opengl"
^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 )
so far so good
so I create a pointer for that array
vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size.
and then take that pointer and insert in each position the individual values from vertexPositions
vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ].
so far so good.
now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created
gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW.
where you see the dots is where I should pass the data, in this case the C array
I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array.
So how I do that ?
I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ?
NBExternalAdress value , returns the number of the address and not that data contained in that address.
I also see a NBExternalArray but I am not sure if it is what I should be using .
Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
> wrote:
I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696807.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Igor one last thing I forgot to ask about b) how I pass the pointer to the function ? Now Camillo , If you guys care about making pharo popular , I mean really popular you should stop caring what you want or what I want and care more about what most people want. Democracy sucks but hey thats the way to fame. I am sorry but I am not buying into the whole argument of self documented code. Why ? Because I dont trust coders. I know however for a fact that as you said it "outside" documentation , assuming its a lengthy one, even if its a bad one, is a much safer bet to make sense , especially for a very big library. If the library is very small sure you can deal with it with class comments and method comments and some random examples. But take Nativeboost for example, understanding Nativeboost without outside documentation is just , well crazy. There so many issues to discuss and many concepts to analyse, and if we take into account that people dealing with Nativeboost are not C coders or experienced with C coding then you will have loads of user with a big questionmark on top of their heads. Sure those people should go read a C code, which I do already , but still would I complain if documentation of NB explained those things to me ? Why would I , I am as lazy as the next person. Plus I am a user why should I care about class comments and methods comments, I dont care how the source works I only care how I can use the library the easiest , quickest way possible. Should classes and methods have their comments ? definitely !!! This is open source , its meant to be read , analyzed and modified. Making people life harder is making it more close source. But I dont believe a user of a library would prioritize class / method comments and code example over old-way hardcore documentation. I seriously believe pharo would greatly benefit from a wiki and would help taking it more seriously. Or at least an included documentation tool inside pharo that will make documentation much easier. I mentioned wikibooks because its based on already highly successful popular technology. If you have better recommendation I am open to any ideas. So in short yes I will comment class/methods of Nativeboost and yes I will contribute to wikibooks as well. Camillo Bruni-3 wrote
I like to see people contributing :), maybe you could do some contribution on the code-side?
I personally consider well written, executable examples more valuable than written documentation outside the image. And I think NativeBoost could benefit from some in-image documentation.
On 2013-07-02, at 14:39, kilon <
thekilon@.co
> wrote:
And I love pharo and what you guys have created , a lot of fun and very productive. So yes I will definitely help you out in documenting NB.
Actually my idea was not to publish in a blog. I hate blogs though I have one I just find it very non flexible so I was thinking instead wikibooks .
http://en.wikibooks.org/wiki/Help:Contributing <http://en.wikibooks.org/wiki/Help:Contributing>
I was thinking moving the entire nativeboost docs (pdf/latex) to wiki books so I make it much easier for everyone can contribute. Wikibooks uses Mediawiki which I am familiar with from the blender wiki when I was making my python book
http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic <http://wiki.blender.org/index.php/User:Kilon/Python_book_of_magic>
Mediawiki is nowhere near as powerful as latex but its way easier to learn and it literally takes minutes to learn the syntax and you dont need a special editor you can do it online directly with minimum syntax. This way everyone can contribute , it only needs an account.
Stéphane Ducasse wrote
I love your questions! When you will get all your anwsers you have to write a blog about it so that we can use that in a chapter so that every body can know how to do it.
Just no time to think right now :( sadly
Stef
On Jul 1, 2013, at 8:40 PM, kilon <
thekilon@.co
> wrote:
Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source.
So for our next challenge is learning how to fetch data that a pointer points to.
in this case I have an array that contains my vertex positions , called vertexPositions
vertexPositions "the positions of vertices to be passed to opengl"
^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 )
so far so good
so I create a pointer for that array
vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size.
and then take that pointer and insert in each position the individual values from vertexPositions
vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ].
so far so good.
now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created
gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW.
where you see the dots is where I should pass the data, in this case the C array
I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array.
So how I do that ?
I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ?
NBExternalAdress value , returns the number of the address and not that data contained in that address.
I also see a NBExternalArray but I am not sure if it is what I should be using .
Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
> wrote:
I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696807.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696870.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 2013-07-02, at 16:47, kilon <thekilon@yahoo.co.uk> wrote:
Igor one last thing I forgot to ask about b) how I pass the pointer to the function ?
Now Camillo , If you guys care about making pharo popular , I mean really popular you should stop caring what you want or what I want and care more about what most people want. Democracy sucks but hey thats the way to fame. I am sorry but I am not buying into the whole argument of self documented code. Why ? Because I dont trust coders.
It's a matter of resources, examples can be executed and run regularly during tests. Which means they work. Documentation, as any other part, rots, but nobody tests it automatically. So keeping external documentation up to date is a significant effort! So you do not trust coders, but you trust people that write documentation? I only trust tests, if tests are green I am happy. Written out documentation is not tested (unless you have a fancy system, which, sadly, we do not have yet). And I think that you can perfectly explain a complex library with step by step examples. Don't get me wrong, I am not against documentation, but I still think it effort put at the wrong place. Just look at Pharo By Example and how much confusion the outdated examples cause...
you can have outdated documentation as you can have buggy code and even outdated code. And yes I would not trust a coder to write proper documentation as much I would trust someone who writes documentation to code or fix a bug. Why ? because its all about motivation, thats why. But you know what , its easy to pick , just ask your users what they want. If they dont want me to contribute to wikibooks and instead contribute to tests, comment classes and methods sure ok I will do it. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696881.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 1 July 2013 20:40, kilon <thekilon@yahoo.co.uk> wrote:
Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source.
So for our next challenge is learning how to fetch data that a pointer points to.
in this case I have an array that contains my vertex positions , called vertexPositions
vertexPositions "the positions of vertices to be passed to opengl"
^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 )
so far so good
so I create a pointer for that array
vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size.
and then take that pointer and insert in each position the individual values from vertexPositions
vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ].
so far so good.
just one small advice: do not use #sizeOf: sparingly.. it parsing the type and doing full type resolution when you do that. you can remember the size of the type you need at boot/startup time, there is no chance it can change within same session :) but of course for demonstration purposes and readability it good.
now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created
gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW.
where you see the dots is where I should pass the data, in this case the C array
I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array.
So how I do that ?
I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ?
just pass NBExternalAdress instance as argument and you done.
NBExternalAdress value , returns the number of the address and not that data contained in that address.
I also see a NBExternalArray but I am not sure if it is what I should be using .
arrayClass := NBExternalArray ofType: 'float'. array := arrayClass new: 5. "or externalNew:5 , if you want to allocate it in external memory" array at: 1 put: 10.1 "use just like normal Array" to pass it to function use: self soemFunction: array address.
Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
wrote: I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Igor got you will try to avoid using #sizeOf: , even for a readability I can replace it with a simple method returning the same thing depending in platform. Now because I am confused lets clarify how the whole things works because I see many errors in my code and clearly I don't understand how Nativeboost works. Note I am a C noob , so excuse me if I say anything stupid here. As far as functions call are concerned I see 3 possible scenariors a ) function(int var). Here the C function expects a simple variable of some type (int in this case) according to what you told me to make such variable I will do var := Nativeboost allocate:( NBExternalType typeof:'int') if I want to pass a value in that variable then I will do var nbInt32AtOffset: 0 put: 6 will call that function with Object function: var b) function(int* var) how I create the variable (pointer) ? how I put value in the variable (pointer) ? c) function( &var) Now I assume I will create a var variable same way as (a) var := Nativeboost allocate:( NBExternalType typeof:'int') but how I pass the address of var to the function ? I read the pdf of nativeboost but It did not clarify those things or simply I did not understand. Thanks on the instructions about NBExternalArray. So the reason of using this object is for convenience ? Igor Stasenko wrote
On 1 July 2013 20:40, kilon <
thekilon@.co
> wrote:
Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source.
So for our next challenge is learning how to fetch data that a pointer points to.
in this case I have an array that contains my vertex positions , called vertexPositions
vertexPositions "the positions of vertices to be passed to opengl"
^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 )
so far so good
so I create a pointer for that array
vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size.
and then take that pointer and insert in each position the individual values from vertexPositions
vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ].
so far so good.
just one small advice: do not use #sizeOf: sparingly.. it parsing the type and doing full type resolution when you do that. you can remember the size of the type you need at boot/startup time, there is no chance it can change within same session :)
but of course for demonstration purposes and readability it good.
now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created
gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW.
where you see the dots is where I should pass the data, in this case the C array
I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array.
So how I do that ?
I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ?
just pass NBExternalAdress instance as argument and you done.
NBExternalAdress value , returns the number of the address and not that data contained in that address.
I also see a NBExternalArray but I am not sure if it is what I should be using .
arrayClass := NBExternalArray ofType: 'float'. array := arrayClass new: 5. "or externalNew:5 , if you want to allocate it in external memory"
array at: 1 put: 10.1 "use just like normal Array"
to pass it to function use:
self soemFunction: array address.
Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
wrote: I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696858.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 2 July 2013 16:27, kilon <thekilon@yahoo.co.uk> wrote:
Igor got you will try to avoid using #sizeOf: , even for a readability I can replace it with a simple method returning the same thing depending in platform.
Now because I am confused lets clarify how the whole things works because I see many errors in my code and clearly I don't understand how Nativeboost works. Note I am a C noob , so excuse me if I say anything stupid here.
As far as functions call are concerned I see 3 possible scenariors
a ) function(int var). Here the C function expects a simple variable of some type (int in this case) according to what you told me to make such variable I will do
var := Nativeboost allocate:( NBExternalType typeof:'int')
if I want to pass a value in that variable then I will do
var nbInt32AtOffset: 0 put: 6
will call that function with
Object function: var
you found very interesting way to pass simple integer to function :) if your function is 'function(int var)' you call it directly: someobject function: 5 x := 10. someobject function: x etc..
b) function(int* var)
how I create the variable (pointer) ?
how I put value in the variable (pointer) ?
pointer = address on memory which holding some value. every time you see '*', it means that function expects pointer. And of course, since that function will write or read from that memory location, it is your responsibility to provide a pointer to valid data, with enough size etc. So, the way how you did for first case, is actually applicable for this case. But it is not necessary to use externally allocated memory. Sometimes you can safely use object memory, e.g.: buffer := ByteArray new: 4. someobject function: buffer.
c) function( &var)
did you meant 'int &var'? because otherwise it is not correct declaration.
Now I assume I will create a var variable same way as (a)
var := Nativeboost allocate:( NBExternalType typeof:'int')
but how I pass the address of var to the function ?
this is reference (more from C++).. which in fact just a syntactic sugar, function still expecting pointer (so consider this to be same as *var)
I read the pdf of nativeboost but It did not clarify those things or simply I did not understand.
Thanks on the instructions about NBExternalArray. So the reason of using this object is for convenience ?
Of course. It is more convenient to deal with array of typed elements (of type you need), than manually deal with bunch of raw bytes.
Igor Stasenko wrote
On 1 July 2013 20:40, kilon <
thekilon@.co
wrote: Thanks Igor , yes I was aware of String Cr because I have done some googling around and it did find information on the subject. Apparently it failed because I had an error in my source.
So for our next challenge is learning how to fetch data that a pointer points to.
in this case I have an array that contains my vertex positions , called vertexPositions
vertexPositions "the positions of vertices to be passed to opengl"
^ #( 0.75 0.75 0.0 1.0 0.75 -0.75 0.0 1.0 -0.75 -0.75 0.0 1.0 )
so far so good
so I create a pointer for that array
vptrsize := (NBExternalType sizeOf: 'float')* self vertexPositions size.
and then take that pointer and insert in each position the individual values from vertexPositions
vertexPositions withIndexDo: [:each :i | "using nbUInt32AtOffset because we know pointer is 4 bytes :) " vpos nbFloat32AtOffset: (i-1)*(NBExternalType sizeOf: 'float') put: each value. Transcript show: ' I am putting to vpos in index: '; show: i-1; show:' value: '; show: each value; cr. ].
so far so good.
just one small advice: do not use #sizeOf: sparingly.. it parsing the type and doing full type resolution when you do that. you can remember the size of the type you need at boot/startup time, there is no chance it can change within same session :)
but of course for demonstration purposes and readability it good.
now the tricky part is that I have a function that expects that Array , not the smalltalk version but the C version we just created
gl bufferData_target: GL_ARRAY_BUFFER size: vptrsize data: ....... usage: GL_STATIC_DRAW.
where you see the dots is where I should pass the data, in this case the C array
I could do a vpo nbFloat32AtOffset: but that will return me only the individual value at the specific point (index) of the array, while I want to pass the entire array.
So how I do that ?
I explored NBExternalAdress and I cant find something that would return an array. Am I missing something obvious here ?
just pass NBExternalAdress instance as argument and you done.
NBExternalAdress value , returns the number of the address and not that data contained in that address.
I also see a NBExternalArray but I am not sure if it is what I should be using .
arrayClass := NBExternalArray ofType: 'float'. array := arrayClass new: 5. "or externalNew:5 , if you want to allocate it in external memory"
array at: 1 put: 10.1 "use just like normal Array"
to pass it to function use:
self soemFunction: array address.
Igor Stasenko wrote
On 30 June 2013 21:11, kilon <
thekilon@.co
wrote: I am not going to post my code here cause it has become too big , you can find it here
http://www.smalltalkhub.com/#!/~kilon/GLTutorial <http://www.smalltalkhub.com/#!/~kilon/GLTutorial>
I tried adding newlines with String cr to my shaders strings, but apparently opengl is not convinced. It looks like smalltalk cr is not converted to C "\n" newlines. So how I do that ?
simply replace all occurences of Character cr with Character lf (or crlf, if it wants that)
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696666.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696858.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
Thank you Igor for the clarifications, the reason why I prefer using the nativeboost methods is because : a) I was not sure if smalltalk types map correctly to C types and which Smalltalk types correspond to which C types b) many opengl functions ask for the address of the value and the value itself. And I have no clue how to obtain memory addresses of smalltalk types. c) I was not sure whether Pharo VM or garbage collector would move my data making my pointers invalid. But if you say its ok, I trust you. When exactly is ok to use smalltalk types ? -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696955.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 2 July 2013 23:04, kilon <thekilon@yahoo.co.uk> wrote:
Thank you Igor for the clarifications, the reason why I prefer using the nativeboost methods is because :
a) I was not sure if smalltalk types map correctly to C types and which Smalltalk types correspond to which C types
well, there's no such thing as 'types' in smalltalk :)
b) many opengl functions ask for the address of the value and the value itself. And I have no clue how to obtain memory addresses of smalltalk types.
you don't. The value can have a type, but address don't. Address is just a location in memory, where the value(s) (could be) stored. For any function which takes a pointer, you can pass an instance of ByteArray, or instance of NBExternalAddress to it. In first case, a pointer to first byte of bytearray will be passed to function, in second one , the value of address. So, you either allocate buffer in object memory, or external memory.. fill it with whatever it needs and pass to function. Does that sounds simple enough?
c) I was not sure whether Pharo VM or garbage collector would move my data making my pointers invalid.
But if you say its ok, I trust you. When exactly is ok to use smalltalk types ?
if you pass a pointer to something in object memory into function, make sure GC cannot move the object while function uses/accessing its contents. and it is only for pointers. For arguments which is passed by value (ints/floats), you don't have to care.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696955.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
yeah I know there is no such thing as types in smalltalk , since everything is an object and the language is dynamic. I was referring to how those objects map to C types. But you are correct it is simpler than I was assuming. The more I think about it the more it makes sense. Igor Stasenko wrote
On 2 July 2013 23:04, kilon <
thekilon@.co
> wrote:
Thank you Igor for the clarifications, the reason why I prefer using the nativeboost methods is because :
a) I was not sure if smalltalk types map correctly to C types and which Smalltalk types correspond to which C types
well, there's no such thing as 'types' in smalltalk :)
b) many opengl functions ask for the address of the value and the value itself. And I have no clue how to obtain memory addresses of smalltalk types.
you don't. The value can have a type, but address don't. Address is just a location in memory, where the value(s) (could be) stored.
For any function which takes a pointer, you can pass an instance of ByteArray, or instance of NBExternalAddress to it. In first case, a pointer to first byte of bytearray will be passed to function, in second one , the value of address.
So, you either allocate buffer in object memory, or external memory.. fill it with whatever it needs and pass to function. Does that sounds simple enough?
c) I was not sure whether Pharo VM or garbage collector would move my data making my pointers invalid.
But if you say its ok, I trust you. When exactly is ok to use smalltalk types ?
if you pass a pointer to something in object memory into function, make sure GC cannot move the object while function uses/accessing its contents.
and it is only for pointers. For arguments which is passed by value (ints/floats), you don't have to care.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4696955.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4697076.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I'm just guessing, but if a function receives a pointer, it does not store the pointer anywhere but works with the contents, and finally returns while VM is blocked, voilá :). On Wed, Jul 3, 2013 at 10:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
if you pass a pointer to something in object memory into function, make sure GC cannot move the object while function uses/accessing its contents.
How?
On 3 July 2013 22:36, Guillermo Polito <guillermopolito@gmail.com> wrote:
I'm just guessing, but if a function receives a pointer, it does not store the pointer anywhere but works with the contents, and finally returns while VM is blocked, voilá :).
Yes.
On Wed, Jul 3, 2013 at 10:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
if you pass a pointer to something in object memory into function, make sure GC cannot move the object while function uses/accessing its contents.
How?
-- Best regards, Igor Stasenko.
ok we should write that in the NB chapter. On Jul 3, 2013, at 10:36 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
I'm just guessing, but if a function receives a pointer, it does not store the pointer anywhere but works with the contents, and finally returns while VM is blocked, voilá :).
On Wed, Jul 3, 2013 at 10:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
if you pass a pointer to something in object memory into function, make sure GC cannot move the object while function uses/accessing its contents.
How?
On Jun 2
Yes, you right. (NBFFICallout new resolveType: 'byte*') valueSize => 1 (NBFFICallout new resolveType: 'byte*') storageSize => 4
apparently, if one wants array with 'byte*' element type (or any other) it should use a pointer size (4), not byte size (1) for it.
Or is a disclaimer not to use the class for, say, 'char*' elements more appropriate?
no , it should be fine. The difference between valueSize and storageSize is a bit confusing, and easy to confuse which to use.. Perhaps they need different naming.
+1 consider that people will use that during 10 years so good comments + names is KEY
There also stackSize, which means "how many bytes a value of given type will take, if pushed on stack , and aligned accordingly"
... after some more investigation, i found that actually storageSize should not be used. There is typeSize instead.
So, the final expression should be:
elementType := aTypeName. elementSize := (NBFFICallout new requestor: self; resolveType: elementType) typeSize.
and #sizeOf: method should also use typeSize apparently.
Cheers, Henry
-- Best regards, Igor Stasenko.
On 27 June 2013 18:32, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jun 2
Yes, you right. (NBFFICallout new resolveType: 'byte*') valueSize => 1 (NBFFICallout new resolveType: 'byte*') storageSize => 4
apparently, if one wants array with 'byte*' element type (or any other) it should use a pointer size (4), not byte size (1) for it.
Or is a disclaimer not to use the class for, say, 'char*' elements more appropriate?
no , it should be fine. The difference between valueSize and storageSize is a bit confusing, and easy to confuse which to use.. Perhaps they need different naming.
+1 consider that people will use that during 10 years so good comments + names is KEY
yes, i always in such mode. But sometimes a right term/word/concept comes after number of interations (until you, as developer finally really understand what you just did or what you actually wanted to do ;)
There also stackSize, which means "how many bytes a value of given type will take, if pushed on stack , and aligned accordingly"
... after some more investigation, i found that actually storageSize should not be used. There is typeSize instead.
So, the final expression should be:
elementType := aTypeName. elementSize := (NBFFICallout new requestor: self; resolveType: elementType) typeSize.
and #sizeOf: method should also use typeSize apparently.
Cheers, Henry
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
participants (10)
-
Camillo Bruni -
Esteban Lorenzano -
Guillermo Polito -
Guy Hylton -
Henrik Johansen -
Igor Stasenko -
kilon -
Marcus Denker -
stephane ducasse -
Stéphane Ducasse