January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] ANN: OpenGL + NativeBoost + Mac ==> success

by Igor Stasenko

On 20 January 2012 22:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 20 January 2012 21:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Hi igor. I am the OpenGL biggest newbie you can find the world. I have just >> reproduced all your steps but I have an error in NBMacGLContextDriver >> >> createContext: initialExtent >> the error is "'invalid pixel format'" >> Any ideas? >> I attach PharoDebug.log >> > > yes. It doesn't works with your hardware :) > Strange that it worked on mine: > Â - 4 years old Mac Pro > Â - lion > > what you can do is go to #createContext: method and play with various > options for > GL pixel format. > > attribs := CGLPixelFormatAttributes for: Â { > Â Â Â Â Â Â Â Â KCGLPFAFullScreen. > Â Â Â Â Â Â Â Â KCGLPFADisplayMask -> self mainDisplayMask. > Â Â Â Â Â Â Â Â KCGLPFADoubleBuffer. > Â Â Â Â Â Â Â Â KCGLPFAColorSize -> 24. > Â Â Â Â Â Â Â Â KCGLPFAAlphaSize -> 8. > Â Â Â Â Â Â Â Â " Â Â Â KCGLRPAccelerated." > Â Â Â Â Â Â Â Â KCGLPFAMultisample. > Â Â Â Â Â Â Â Â KCGLPFASampleAlpha. > Â Â Â Â Â Â Â Â KCGLPFASamples -> 8. > Â Â Â Â Â Â Â Â 0 > Â Â Â Â Â Â Â Â }. > > you should be able to create a context.. but of course it is a big > question if with your format my demo will still run , because it wants > some extensions :) > i'd like to add that creating an openGL context is the most delicate part of initialization. On all platforms without exception. Once you obtained it (hopefully with right capabilities), the rest is a piece of cake. > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Jan. 20, 2012

Re: [Pharo-project] [squeak-dev] ANN: OpenGL + NativeBoost + Mac ==> success

by Igor Stasenko

On 20 January 2012 21:04, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi igor. I am the OpenGL biggest newbie you can find the world. I have just > reproduced all your steps but I have an error in NBMacGLContextDriver >> > createContext: initialExtent > the error is "'invalid pixel format'" > Any ideas? > I attach PharoDebug.log > yes. It doesn't works with your hardware :) Strange that it worked on mine: - 4 years old Mac Pro - lion what you can do is go to #createContext: method and play with various options for GL pixel format. attribs := CGLPixelFormatAttributes for: { KCGLPFAFullScreen. KCGLPFADisplayMask -> self mainDisplayMask. KCGLPFADoubleBuffer. KCGLPFAColorSize -> 24. KCGLPFAAlphaSize -> 8. " KCGLRPAccelerated." KCGLPFAMultisample. KCGLPFASampleAlpha. KCGLPFASamples -> 8. 0 }. you should be able to create a context.. but of course it is a big question if with your format my demo will still run , because it wants some extensions :) -- Best regards, Igor Stasenko.

Jan. 20, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by Igor Stasenko

On 9 January 2012 02:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > It's not a problem at all, because the correct solution is supported - it > just needs better exposure in the Spock chapter. > Sure it is there. Lately , when Spock chapter was under writing we decided to add a convenience interface, so you can type less to define a callout. Here how it usually looks like today: CGMainDisplayID <primitive: #primitiveNativeCall module: #NativeBoostPlugin> "Returns the display ID of the main display." ^ self nbCall: #( CGDirectDisplayID CGMainDisplayID ( void ) ) module: self ApplicationServices but you can also omit #module: keyword, if you implement #nbLibraryNameOrHandle in your class. so you can leave it with just: ^ self nbCall: #( CGDirectDisplayID CGMainDisplayID ( void ) ) Also, ultimately you can override #nbGetSymbolAddress: aName module: aModuleNameOrHandle to redefine completely semantics where and how your class should look for given symbol (function) and obtain a pointer to it. > > \ > ________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez > Peck [marianopeck(a)gmail.com] > Sent: Sunday, January 08, 2012 5:59 PM > > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Best way for FFI in Pharo > > > > On Sun, Jan 8, 2012 at 11:53 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > wrote: >> >> I am just the messenger: the library names are different on the various >> platforms, > > > Yes, but that's not a problem with the solution I have just mentioned. No > need to change anything. > >> >> and the names can change over time (especially on Linux). >> > > yes, but that's why I meant this is not that frequent at all. How many times > it change? once a year? > And that's why I recommended having a small script to change it. > So again, I don't see this like a critical problem of FFI. > >> >> >> ________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez >> Peck [marianopeck(a)gmail.com] >> Sent: Sunday, January 08, 2012 5:33 PM >> >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Best way for FFI in Pharo >> >> >> >> On Sun, Jan 8, 2012 at 11:26 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >> wrote: >>> >>> Why do it (automated or not) 2000 times when it can be done once? >> >> >> I don't understand. Why should I need to change the module name so >> frequently?Â I have been working with squeakDBX since 4 years and we never >> needed to change it. >> >>> >>> Think of the wasted time and change log bloat.Â Would you like to do it >>> every time you move from Windows to Linux and back? >> >> >> I don't understand why you say you should change that when moving from one >> OS to another one. I think you may have design issue, not FFI. With DBXTalk >> we have the superclass PharoOpenDBX, with has all the openDBX api with >> methods ^Â self subclassResponsability. That's to mark the API. Then we have >> 2 subclasses, OpenDBXUnix and OpenDBXWindows. And then OpenDBXMac which is >> subclass from the Unix one but doesn't change or add anything so far. >> Then we have a Current (singleton) stored in a class variable and a class >> side initialize that does >> >> ffiImplementationForOS >> Â Â Â | platformName | >> Â Â Â platformName := Smalltalk os platformName. >> Â Â Â platformName = 'Win32' ifTrue:[ ^OpenDBXWin32 basicNew initialize]. >> Â Â Â platformName = 'unix' ifTrue:[ ^OpenDBXUnix basicNew initialize]. >> Â Â Â platformName = 'Mac OS' ifTrue:[ ^OpenDBXMacOSX basicNew initialize]. >> Â Â Â self error: 'Cannot identify platform'. >> >> And that's all. We never need to change anything.Â The only thing you >> should care is if moving the same image from one OS to another one then you >> have to reinitialize this class variable.Â Or...you could add it to startUp >> list if you want. >> >> Cheers >> >>> >>> Say it once.Â The superiority of #moduleName is clear. >>> >>> >>> >>> ________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez >>> Peck [marianopeck(a)gmail.com] >>> Sent: Sunday, January 08, 2012 4:29 PM >>> >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Best way for FFI in Pharo >>> >>> >>> >>> On Sun, Jan 8, 2012 at 10:13 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>> wrote: >>>> >>>> Agreed, except for thinking that changing all of the module names is not >>>> a big deal :) >>> >>> >>> Why not? how many smalltalk lines of code do you think it could take to >>> automate that? ;) >>> >>> >>>> >>>> Â An external library subclass is the way to go.Â I know this already >>>> exists in FFI, but the evolving chapter on Spock does not mention it - it >>>> should not only mention it, but recommend it, IMHO. >>>> >>>> Stef, does it make sense yet? >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>> [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Mariano Martinez >>>> Peck [marianopeck(a)gmail.com] >>>> Sent: Sunday, January 08, 2012 3:52 PM >>>> >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] Best way for FFI in Pharo >>>> >>>> >>>> >>>> On Sun, Jan 8, 2012 at 9:25 PM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>> can you give an example that I understand >>>>> "One thing I strongly recommend is to favor #moduleName over pragmas >>>>> listing the library - imagine changing 2000+ GSL calls if the library name >>>>> changes =:0 " >>>>> >>>> >>>> Bill:Â that already exists in FFI. >>>> Stef: what Bill says is that if you bind to a specific library you have >>>> to put its library name in each method that calls a ffi function. Example of >>>> DBX: >>>> >>>> apiErrorType: handle number: err >>>> Â Â Â "int odbx_error_type( odbx_t*, int )" >>>> Â Â Â <cdecl: long 'odbx_error_type' (ulong long) module: 'opendbx'> >>>> Â Â Â ^ self externalCallFailed >>>> >>>> ---- >>>> >>>> apiInitialize: handle backend: backend host: host port: port >>>> Â Â Â "long odbx_init(odbx_t**, char*, char*, char*)" >>>> Â Â Â <cdecl: long 'odbx_init' (ulong* char* char* char*) module: >>>> 'opendbx'> >>>> Â Â Â ^self externalCallFailed >>>> >>>> --- >>>> >>>> xxx >>>> >>>> --- >>>> >>>> Notice the "module: 'opendbx" >>>> So...if now the library is renamed or whatever, you have to change all >>>> methods. But I don't think this is a real big deal. There are much worst >>>> things. >>>> >>>> Finaly, I copy paste an answer from Andreas from a previous thread: >>>> >>>> >>>> The Right Way to do this is to have a subclass of ExternalLibrary and >>>> implement the class-side method #moduleName along the lines of: >>>> >>>> MyLibrary class>>moduleName >>>> Â "Answer the module name to use for this library" >>>> Â Smalltalk platformName = 'Win32' ifTrue:[^'MyLibrary32.dll']. >>>> Â Smalltalk platformName = 'unix' ifTrue:[ >>>> Â Â "check various locations and versions" >>>> Â Â #('/usr/lib/libMyLibrary.so' >>>> Â Â Â '/usr/lib/libMyLibrary.so.1' >>>> Â Â Â '/usr/lib/libMyLibrary.so.2' >>>> Â Â Â '/usr/share/libMyLibrary.so.1' >>>> Â Â Â '/usr/share/libMyLibrary.so.2' >>>> ) do:[:location| >>>> Â Â Â Â Â (FileDirectory fileExists: location) ifTrue:[^location]. >>>> Â Â ]. >>>> Â Â ^self error:'MyLibrary is not installed' >>>> Â ]. >>>> >>>> >>>>> >>>>> Tx >>>>> >>>>> On Jan 8, 2012, at 9:18 PM, Schwab,Wilhelm K wrote: >>>>> >>>>> > Stef, >>>>> > >>>>> > Absent the NB experience, +1 to the comments below. Â FFI has pretty >>>>> > much "just worked" for me. Â We need double arrays. Â Callbacks would be >>>>> > great. Â One thing I strongly recommend is to favor #moduleName over pragmas >>>>> > listing the library - imagine changing 2000+ GSL calls if the library name >>>>> > changes =:0 Â It makes a LOT more sense to have a class per library, and that >>>>> > class knows the name to use. Â That's all the more true when one considers >>>>> > code such as ODBC that can run on multiple platforms with different names. >>>>> > Â #moduleName can test the OS and answer the correct name. >>>>> > >>>>> > Bill >>>>> > >>>>> > >>>>> > ________________________________________ >>>>> > From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> > [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse >>>>> > [stephane.ducasse(a)inria.fr] >>>>> > Sent: Sunday, January 08, 2012 2:16 PM >>>>> > To: Pharo-project(a)lists.gforge.inria.fr >>>>> > Subject: Re: [Pharo-project] Best way for FFI in Pharo >>>>> > >>>>> > thanks for the feedback. >>>>> > We will come back you soon :) >>>>> > Because we should get FFI and NativeBoost fully working :). >>>>> > >>>>> > Stef >>>>> > >>>>> > On Jan 8, 2012, at 7:29 PM, ncalexan wrote: >>>>> > >>>>> >> >>>>> >> fstephany wrote >>>>> >>> >>>>> >>> I'm also a bit lost between all the different options (plugins, >>>>> >>> NativeBoost, FFI, Alien). >>>>> >>> >>>>> >> >>>>> >> I also found this confusing, so let me tell my recent experience and >>>>> >> my >>>>> >> conclusion. >>>>> >> >>>>> >> I have written bindings to the SDL game programming library for use >>>>> >> with >>>>> >> Pharo. Â SDL is cross-platform, and I want to support Mac (most of >>>>> >> all), >>>>> >> Windows (one must), and Linux (if I must). Â As far as I can tell, >>>>> >> Alien is >>>>> >> not cross-platform and not maintained, so I have not spent time >>>>> >> investigating it. >>>>> >> >>>>> >> Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs >>>>> >> package >>>>> >> which parses the relevant C header files and then writes either an >>>>> >> NB or FFI >>>>> >> callout class tree. Â I need to define a few structures, make a class >>>>> >> pool >>>>> >> with some constants, and then define lots of callouts, many of which >>>>> >> take >>>>> >> references to structures (like 'foo(struct x*)'). >>>>> >> >>>>> >> I was able to make both work, more or less, on my Macbook Pro, using >>>>> >> stock >>>>> >> Pharo 1.3 images and Igor's NBCog.app. >>>>> >> >>>>> >> I found NB to be a nicer programmer experience but I found that the >>>>> >> FFI just >>>>> >> works. Â There are a lot of gratuitous differences, but: >>>>> >> >>>>> >> * NB requires a VM compiled with a separate plugin (that I built >>>>> >> from source >>>>> >> with no trouble -- Igor has done splendid work with CMakeVMMaker). >>>>> >> * NB should be faster than the FFI at pretty much everything, but I >>>>> >> can't >>>>> >> say since I haven't measured. >>>>> >> * NB has useful primitives for determining if your external objects >>>>> >> are >>>>> >> still valid and for determining the current operating system (I >>>>> >> intend to >>>>> >> use these even if I don't use NB). >>>>> >> * NB has very few tests and examples and essentially no >>>>> >> documentation. >>>>> >> * NB has a simple conceptual model, but it is still not as simple as >>>>> >> the FFI >>>>> >> model. >>>>> >> * NB uses variableByteClasses to great advantage -- this is very >>>>> >> cool. >>>>> >> >>>>> >> * NB makes it easy to crash your image, since you are evaluating >>>>> >> native code >>>>> >> in image. >>>>> >> * NB is still, to my eye, raw and untested on Mac. Â I had problems >>>>> >> with >>>>> >> stack alignments in bizarre places, and NB's interaction with >>>>> >> garbage >>>>> >> collection basically ended my attempts to use it. >>>>> >> * NB is basically impossible to debug if you aren't very strong with >>>>> >> x86 >>>>> >> assembly (I'm not even strong with x86 assembly), and the stack >>>>> >> manipulations rendered GDB pretty much useless for me. >>>>> >> * NB does not integrate well with the Pharo tools -- I think the >>>>> >> MethodTrailers are screwing up references, implementors, and source >>>>> >> views, >>>>> >> but I haven't investigated. >>>>> >> * NB does not seem to support indirections very easily -- I >>>>> >> struggled to >>>>> >> understand how to interface to foreign C functions with specs like >>>>> >> 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and >>>>> >> eventually >>>>> >> gave up. >>>>> >> >>>>> >> I wanted to help Igor with the NB project, but the NB-OpenGL Mac >>>>> >> bindings >>>>> >> crash horribly for me, and although I was able to fix them, it I >>>>> >> just don't >>>>> >> hack enough x86 assembly to figure out all the tricks Igor is doing. >>>>> >> Â The >>>>> >> thought of making it all work on 3 platforms, and fix all the tool >>>>> >> integration, was just too much for me. >>>>> >> >>>>> >> In conclusion, I prefer the FFI. Â It is old, cross platform, well >>>>> >> tested, >>>>> >> somewhat documented, and reliable. Â I think Igor has done some >>>>> >> amazing work >>>>> >> and I do not want to bash his project (and certainly not his code -- >>>>> >> the >>>>> >> man's a magician) but the fancy features are not necessary for my >>>>> >> project. >>>>> >> >>>>> >> >>>>> >> fstephany wrote >>>>> >>> >>>>> >>> Will this interface handle callbacks ? >>>>> >>> >>>>> >> >>>>> >> I do not need callbacks so cannot speak to this issue. >>>>> >> >>>>> >> Yours, >>>>> >> Nick Alexander >>>>> >> >>>>> >> -- >>>>> >> View this message in context: >>>>> >> http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html >>>>> >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

Jan. 20, 2012

Re: [Pharo-project] Best way for FFI in Pharo

by Igor Stasenko

Thanks, a lot for your first-hand experience. On 8 January 2012 20:29, ncalexan <ncalexander(a)gmail.com> wrote: > > fstephany wrote >> >> I'm also a bit lost between all the different options (plugins, >> NativeBoost, FFI, Alien). >> > > I also found this confusing, so let me tell my recent experience and my > conclusion. > > I have written bindings to the SDL game programming library for use with > Pharo. Â SDL is cross-platform, and I want to support Mac (most of all), > Windows (one must), and Linux (if I must). Â As far as I can tell, Alien is > not cross-platform and not maintained, so I have not spent time > investigating it. > > Following Igor Stasenko's OpenGLSpecs package, I wrote an SDLSpecs package > which parses the relevant C header files and then writes either an NB or FFI > callout class tree. Â I need to define a few structures, make a class pool > with some constants, and then define lots of callouts, many of which take > references to structures (like 'foo(struct x*)'). Do you have it available somewhere? > > I was able to make both work, more or less, on my Macbook Pro, using stock > Pharo 1.3 images and Igor's NBCog.app. > > I found NB to be a nicer programmer experience but I found that the FFI just > works. Â There are a lot of gratuitous differences, but: > > * NB requires a VM compiled with a separate plugin (that I built from source > with no trouble -- Igor has done splendid work with CMakeVMMaker). > * NB should be faster than the FFI at pretty much everything, but I can't > say since I haven't measured. > * NB has useful primitives for determining if your external objects are > still valid and for determining the current operating system (I intend to > use these even if I don't use NB). > * NB has very few tests and examples and essentially no documentation. :) Yes, i should start writing it. I was waiting till project will mature enough & stabilize a bit. and of course i am lazy. > * NB has a simple conceptual model, but it is still not as simple as the FFI > model. yep. a bit more concepts, because a bit more features. > * NB uses variableByteClasses to great advantage -- this is very cool. > > * NB makes it easy to crash your image, since you are evaluating native code > in image. this statement can be applied to any FFInterface, if you declare function with wrong types/arguments or pass wrong argument values. :) I spent last 3 days rewriting aligment interface, and hacking opengl glue code, and guess what: it never crashed on me. And yes, i saving image every time before going to run the freshly hacked assembly code :) > * NB is still, to my eye, raw and untested on Mac. Â I had problems with > stack alignments in bizarre places, and NB's interaction with garbage > collection basically ended my attempts to use it. need more data, data pls. I refined a stack-aligned interface recently, and don't have any problems with alignment.. but sure, i maybe lack of real-world experience ;) > * NB is basically impossible to debug if you aren't very strong with x86 > assembly (I'm not even strong with x86 assembly), and the stack > manipulations rendered GDB pretty much useless for me. well, you don't have to go there. Usually i takes less time to grok assembler code in image to find an error than trying to understand what happens in GDB.. in text mode... ohhhhhh :) > * NB does not integrate well with the Pharo tools -- I think the > MethodTrailers are screwing up references, implementors, and source views, > but I haven't investigated. Hmm.. there should be everything fine there. Trailers are not stripping any interpreter-specific state, just adds own on top of it. > * NB does not seem to support indirections very easily -- I struggled to > understand how to interface to foreign C functions with specs like > 'foo(struct x)', 'foo(struct x *)' and 'foo(struct x **)', and eventually > gave up. consider following: struct x k; struct x * l = &k; struct x ** m = &l; "struct x" foo (k); << push &k, because all structs are passed by reference. "struct x * " foo (l); << push value of l = &k "struct x **" foo (m); << push value of m = &l &l obviously <> &k becasue &k points to first byte of your structure, while &l points to first byte of _pointer_ to that structure. usually a ** used in cases when function wants to store result on success. It is like say: give me a memory location where i should store a pointer to that structure, so you can use it later. Unfortunately there is no way to automate that. It means that if you owning a structure, myStruct = NBExternalStructureSubclass new. passing it as argument to functions which takes struct x** may be dangerous. So, in case if function under the question wants to return a pointer to struct back to you, you can do just following: - change the function declaration to following: #( void foo ( NBExternalAddress * address ) ) "this stands for void foo(struct **x) " in this case NB will not push the value of address , but a place in memory where this pointer is stored. Function then writes a new address value there. and so you can use it later by simply: addr := NBExternalAddress new. self foo: addr. mystruct := NBExternalStructure fromPointer: addr. and now you can access the values in struct: mystruct x = 5 ifTrue: [...] If function may want not only to give you address back, but also may want to read your struct fields by occasion, then you have no choice but to use external memory: myStruct := MyExternalStruct new. myStruct x: 4; y 5; ... etc.. externalSpace := NativeBoost allocate: myStruct class instanceSize. NativeBoost memcpy: myStruct to: externalSpace size: myStruct class instanceSize. now, if you pass externalSpace in same way: self foo: externalSpace it will push an address to that address, where copy of your structure lies ;) Now, i would like to know how you solving this with FFI. > > I wanted to help Igor with the NB project, but the NB-OpenGL Mac bindings > crash horribly for me, and although I was able to fix them, it I just don't > hack enough x86 assembly to figure out all the tricks Igor is doing. Â The > thought of making it all work on 3 platforms, and fix all the tool > integration, was just too much for me. > Now it should work fine, so no worries :) Just remember: Communication is the key. I am not dead, and i willing to help anyone who using NativeBoost, So, please, send me feedback, troublesome code, or even whole image(s) and do not hesitate to contact with me. Because it is two way road: i helping you to make it work, you helping me to get rid of defects and misconceptions and missing features. :) > In conclusion, I prefer the FFI. Â It is old, cross platform, well tested, > somewhat documented, and reliable. Â I think Igor has done some amazing work > and I do not want to bash his project (and certainly not his code -- the > man's a magician) but the fancy features are not necessary for my project. > > > fstephany wrote >> >> Will this interface handle callbacks ? >> > > I do not need callbacks so cannot speak to this issue. > > Yours, > Nick Alexander > > -- > View this message in context: http://forum.world.st/Best-way-for-FFI-in-Pharo-tp4275467p4276356.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Jan. 20, 2012

Re: [Pharo-project] [squeak-dev] ANN: OpenGL + NativeBoost + Mac ==> success

by Mariano Martinez Peck

Hi igor. I am the OpenGL biggest newbie you can find the world. I have just reproduced all your steps but I have an error in NBMacGLContextDriver >> createContext: initialExtent the error is "'invalid pixel format'" Any ideas? I attach PharoDebug.log Cheers On Fri, Jan 20, 2012 at 7:52 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Today i'm happy to announce that i can run my 2 years-old demo which i > did when created NBOpenGL bindings first on Windows, > working without ANY changes in code on Mac. > > The main hurdle with adding MacOsx support was that it is largely > unknown platform to me , and there are 3 different ways to get there, > namely CGL, Carbon and Cocoa. > Fortunately CGL approach worked well, despite its a bit limited (you > cannot create a windowed context, only fullscreen or offscreen one). > But since i am using FBO's , it doesn't really matters. > Of course it may make difference for people who want to use GL in > different setup. > > In order to load project, take a fresh Pharo 1.4 image, load > > ConfigurationOfNBOpenGL package using MC from > > MCHttpRepository > location: 'http://www.squeaksource.com/NBOpenGL' > user: 'sig' > password: '' > > > or by > > Gofer it > squeaksource: 'NBOpenGL'; > package: 'ConfigurationOfNBOpenGL'; > load > > and then issue: > > ConfigurationOfNBOpenGL project lastVersion load. > > Remember, that you have to use CogVM with NativeBoost plugin, which > you can download from here: > > > https://ci.lille.inria.fr/pharo/view/NativeBoost/job/NB-Cog-Mac-Carbon/last… > > > If everything goes well, you should be able to run a demo by doing: > > GLTTRenderingDemo new openInWorld. > > P.S. @ Windows users: due to refactorings which i did, a > windows-specific support code is currently broken. So please use older > versions of packages (prior to this month). > I will fix them very soon. > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Jan. 20, 2012

Re: [Pharo-project] [squeak-dev] Re: Saga of trying to integrate IDE with OpenGL continuesRe:

by Igor Stasenko

On 20 January 2012 01:29, Lawson English <lenglish5(a)cox.net> wrote: > Apparently there was a glError that I wasn't catching, so the disk address > issue has gone away: the Baloon3D plugin was logging errors I didn't catch. > > However, I'm not sure how to efficiently blit GUI updates to the gl texture, > so suggestions appreciated. > > Looking at the Squeak3D.log file, it seems to me that Baloon3D already has > access to all the values that Igor is using to setup his NBOpenGL and > GLCanvas packages. Would it be better to leverage that as a cross-platform > initialization for OpenGL instead of another plugin? > My point is following: the more logic you put into VM code (plugin etc), the more limited you are. Because instead of deciding by yourself, what you prefer and what not, someone else deciding for you. I hate constraints, especially in such performance sensitive areas as graphics, where changing a single flag value could mean 10x difference in performance (if not 100x). If we ever need some helpers from VM side is mainly glue code to obtain some handles to resources (like main window handle, etc). But all levers of controls should be at language side, VM should serve as a dummy servant who has no idea what you going to do and just strictly following your orders. > From Squeak3D log: > > > ### Attempting to find hardware renderer > Â Â x: 0 > Â Â y: 0 > Â Â w: 638 > Â Â h: 475 > > > Selected pixel format: > Â Â Â Â AGL_RENDERER_ID Â Â : 0x1021A02 > Â Â Â Â AGL_OFFSCREEN Â Â Â : GL_FALSE > Â Â Â Â AGL_FULLSCREEN Â Â Â : GL_FALSE > Â Â Â Â AGL_WINDOW Â Â Â Â Â : GL_TRUE > Â Â Â Â AGL_ACCELERATED Â Â : GL_TRUE > Â Â Â Â AGL_ROBUST Â Â Â Â Â : GL_FALSE > Â Â Â Â AGL_BACKING_STORE Â : GL_FALSE > Â Â Â Â AGL_MP_SAFE Â Â Â Â : GL_TRUE > Â Â Â Â AGL_COMPLIANT Â Â Â : GL_TRUE > Â Â Â Â AGL_MULTISCREEN Â Â : GL_TRUE > Â Â Â Â AGL_BUFFER_SIZE Â Â : 32 > Â Â Â Â AGL_LEVEL Â Â Â Â Â : 0 > Â Â Â Â AGL_PIXEL_SIZE Â Â Â : 32 > Â Â Â Â AGL_DEPTH_SIZE Â Â Â : 24 > Â Â Â Â AGL_STENCIL_SIZE Â Â : 8 > Â Â Â Â Â Â AGL_3_BIT > Â Â Â Â AGL_AUX_BUFFERS Â Â : 0 > > OpenGL vendor: ATI Technologies Inc. > OpenGL renderer: ATI Radeon HD 2600 OpenGL Engine > OpenGL version: 2.1 ATI-1.6.36 > OpenGL extensions: GL_ARB_transpose_matrix GL_ARB_vertex_program > GL_ARB_vertex_blend GL_ARB_window_pos GL_ARB_shader_objects > GL_ARB_vertex_shader GL_ARB_shading_language_100 GL_EXT_multi_draw_arrays > GL_EXT_clip_volume_hint GL_EXT_rescale_normal GL_EXT_draw_range_elements > GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_geometry_shader4 > GL_EXT_transform_feedback GL_APPLE_client_storage GL_APPLE_specular_vector > GL_APPLE_transform_hint GL_APPLE_packed_pixels GL_APPLE_fence > GL_APPLE_vertex_array_object GL_APPLE_vertex_program_evaluators > GL_APPLE_element_array GL_APPLE_flush_render GL_APPLE_aux_depth_stencil > GL_NV_texgen_reflection GL_NV_light_max_exponent GL_IBM_rasterpos_clip > GL_SGIS_generate_mipmap GL_ARB_imaging GL_ARB_point_parameters > GL_ARB_texture_env_crossbar GL_ARB_texture_border_clamp GL_ARB_multitexture > GL_ARB_texture_env_add GL_ARB_texture_cube_map GL_ARB_texture_env_dot3 > GL_ARB_multisample GL_ARB_texture_env_combine GL_ARB_texture_compression > GL_ARB_texture_mirrored_repeat GL_ARB_shadow GL_ARB_depth_texture > GL_ARB_shadow_ambient GL_ARB_fragment_program GL_ARB_fragment_program_shadow > GL_ARB_fragment_shader GL_ARB_occlusion_query GL_ARB_point_sprite > GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object > GL_ARB_pixel_buffer_object GL_ARB_draw_buffers GL_ARB_shader_texture_lod > GL_ARB_color_buffer_float GL_ARB_half_float_vertex GL_ARB_texture_rg > GL_ARB_texture_compression_rgtc GL_ARB_framebuffer_object > GL_EXT_compiled_vertex_array GL_EXT_draw_buffers2 GL_EXT_framebuffer_object > GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample > GL_EXT_texture_rectangle GL_ARB_texture_rectangle GL_EXT_texture_env_add > GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract > GL_EXT_texture_lod_bias GL_EXT_abgr GL_EXT_bgra GL_EXT_stencil_wrap > GL_EXT_texture_filter_anisotropic GL_EXT_separate_specular_color > GL_EXT_secondary_color GL_EXT_blend_func_separate GL_EXT_shadow_funcs > GL_EXT_stencil_two_side GL_EXT_texture_compression_s3tc > GL_EXT_texture_compression_dxt1 GL_EXT_texture_sRGB > GL_EXT_blend_equation_separate GL_EXT_texture_mirror_clamp > GL_EXT_packed_depth_stencil GL_EXT_bindable_uniform GL_EXT_texture_integer > GL_EXT_gpu_shader4 GL_EXT_framebuffer_sRGB GL_EXT_provoking_vertex > GL_APPLE_flush_buffer_range GL_APPLE_ycbcr_422 GL_APPLE_rgb_422 > GL_APPLE_vertex_array_range GL_APPLE_texture_range GL_APPLE_float_pixels > GL_ATI_texture_float GL_ARB_texture_float GL_ARB_half_float_pixel > GL_APPLE_pixel_buffer GL_APPLE_object_purgeable GL_NV_blend_square > GL_NV_fog_distance GL_NV_conditional_render GL_ATI_texture_mirror_once > GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax > GL_ATI_texture_env_combine3 GL_ATI_separate_stencil > GL_ATI_texture_compression_3dc GL_SGIS_texture_edge_clamp > GL_SGIS_texture_lod GL_SGI_color_matrix GL_EXT_texture_array > GL_EXT_vertex_array_bgra GL_ARB_instanced_arrays GL_ARB_depth_buffer_float > GL_EXT_packed_float GL_EXT_texture_shared_exponent > ### Renderer created! (id = 0) > > > > > > > > On 1/18/12 1:31 PM, Lawson English wrote: >> >> sigh, I'm getting disk access constantly when my little GUI opengl thingie >> runs. The max FPS is 10ish. >> Package is: OpenGL-Tutorial-LDE.32 >> in monticello repository: >> 'http://croquet-src-01.oit.duke.edu:8886/Contributions' >> >> >> suggestions? >> >> >> Thanks. >> >> L. >> >> >> > > -- Best regards, Igor Stasenko.

Jan. 20, 2012

[Pharo-project] ANN: OpenGL + NativeBoost + Mac ==> success

by Igor Stasenko

Today i'm happy to announce that i can run my 2 years-old demo which i did when created NBOpenGL bindings first on Windows, working without ANY changes in code on Mac. The main hurdle with adding MacOsx support was that it is largely unknown platform to me , and there are 3 different ways to get there, namely CGL, Carbon and Cocoa. Fortunately CGL approach worked well, despite its a bit limited (you cannot create a windowed context, only fullscreen or offscreen one). But since i am using FBO's , it doesn't really matters. Of course it may make difference for people who want to use GL in different setup. In order to load project, take a fresh Pharo 1.4 image, load ConfigurationOfNBOpenGL package using MC from MCHttpRepository location: 'http://www.squeaksource.com/NBOpenGL' user: 'sig' password: '' or by Gofer it squeaksource: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load and then issue: ConfigurationOfNBOpenGL project lastVersion load. Remember, that you have to use CogVM with NativeBoost plugin, which you can download from here: https://ci.lille.inria.fr/pharo/view/NativeBoost/job/NB-Cog-Mac-Carbon/last… If everything goes well, you should be able to run a demo by doing: GLTTRenderingDemo new openInWorld. P.S. @ Windows users: due to refactorings which i did, a windows-specific support code is currently broken. So please use older versions of packages (prior to this month). I will fix them very soon. -- Best regards, Igor Stasenko.

Jan. 20, 2012

[Pharo-project] speeding up copying World using dirty rectangles?

by Lawson English

in my Gui to OpenGL code, I'm doing a very naive procedure to copy the World to an OpenGL at every #step. I know that there's many ways to speed this up (I get only 10fps with a saturated core when I do it the simplest way). Suggestsion on how to make the following more efficient? THanks. getLatestImageFromWorld |format form tempTextures| pasteUpFormCanvas ifNil: [^self]. self hide. myPasteUp fullDrawOn: pasteUpFormCanvas. self show. form := pasteUpFormCanvas form. fPUWidth := form width. fPUHeight := form height. tempTextures := WordArray with: (textureIntNames at: 1). ogl glDeleteTextures: 1 with: tempTextures. ogl glBindTexture: GLTexture2d with: (textureIntNames at: 1). ogl checkForError. format := ogl textureInternalFormat. ogl glEnable: GLTexture2d. ogl glTexParameteri: GLTexture2d with: GLTextureMinFilter with: GLLinear. ogl glTexParameteri: GLTexture2d with: GLTextureMagFilter with: GLLinear. ogl glTexImage2D: GLTexture2d with: 0 with: format with: form width with: form height with: 0 with: ogl texturePixelFormat with: ogl texturePixelType with: form bits.

Jan. 20, 2012

Re: [Pharo-project] Which COG VM?

by Garret Raziel

Perhaps you can try using squeakvm as VM. I had several problems with Cog (on my linux), but squeakvm runs without problem. I don't want to judge, but I think that Cog is pretty much faster, but squeakvm is solid. Jan

Jan. 20, 2012

[Pharo-project] Which COG VM?

by Torsten Bergmann

Unfortunately the VM from the one click package has a bug when it comes to FFI. You can download latest Cog from Eliots archive: http://www.mirandabanda.org/files/Cog/VM/?C=M;O=D No need to compile here. I use them too. Note that Eliots one (with source managed in subversion) is not the "official pharo VM", but the "official CogVM" for Squeak and Pharo. Pharo has its own fork and which is github managed. >From time to time Igor moves fixes from Eliots CogVM into the Pharo Cog VM. At least thats how I understood it ... Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Jan. 20, 2012