Understanding NBOpenGL
Locked
1234
1234
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
 
|
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. > 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. > |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by 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 <[hidden email]> wrote: > On 27 June 2013 17:14, Henrik Johansen <[hidden email]> 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. > |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by Stéphane Ducasse
On 27 June 2013 18:32, Stéphane Ducasse <[hidden email]> 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 > 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. |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by Stéphane Ducasse
On 27 June 2013 18:33, Stéphane Ducasse <[hidden email]> 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 :) |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 27 June 2013 21:25, kilon <[hidden email]> 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 ?
|
|
|
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/ dont know if this bug has any effect , or maybe not a bug ? |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 28 June 2013 13:11, kilon <[hidden email]> 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 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 ? |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 30 June 2013 21:11, kilon <[hidden email]> 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 .
|
|
|
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 :)
|
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by kilon
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 <[hidden email]> 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. > |
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
In reply to this post by kilon
On 1 July 2013 20:40, kilon <[hidden email]> 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. |
|
|
In reply to this post by Stéphane Ducasse
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 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 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.
|
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
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 <[hidden email]> 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. > |
|
|
In reply to this post by 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 ?
|
|
|
In reply to this post by Camillo Bruni-3
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.
|
Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL
|
|
On 2013-07-02, at 16:47, kilon <[hidden email]> 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... |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |