- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NativeBoost and C++ libraries

by Igor Stasenko

On 9 December 2011 11:10, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi Igor, > > do you have some experiences with NativeBoost bindings to C++ > libraries (with classes)? I have seen that Ruby has some interface > generators for that purpose (Rice, rb++). No. In C++ things are different (mangled function names, thiscall calling convertion etc). I think it is possible to make FFI to C++ libs, by studying the C++ ABI :) -- Best regards, Igor Stasenko.

Dec. 9, 2011

[Pharo-project] NBOpenGL

by Igor Stasenko

(resending message due to mailer problem) Since it works now only for Windows, Â i didn't thought a lot about platform-neutral stuff. Creating and initializing an opengl context is platform-specific, and it is hard to tell what you may need to create it. Regarding opengl on mac: - i just uploaded the initial snapshot of opengl bindings for mac, see NBOpenGL-Mac package. it can create a context using NBMacContextManager new createContext but i am a bit puzzled what to do next, because it looks like CGL library allows you to create only a fullscreen contexts, and only Carbon/Cocoa frameworks allowing you to make a windowed context by attaching context to specific 'drawable'. So, Fernando (or others), if you know more, take a look what can be done. Maybe it was a mistake to use CGL interface for it, maybe i should write bindings using Carbon interface, but since it promised by apple to be deprecated and removed from system, i don't know what to do (and Cocoa is an Objective-C, and making calls to Objective-C code is completely different story). On 9 December 2011 11:34, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 09.12.2011 11:27, Henrik Sperre Johansen wrote: >> >> >> That's not specific to offscreen rendering contexts though, (nor >> pixelformats, another windows artifact) > > I should perhaps say; they're not Windows specific as such, but the > implementation in NBOpenGL is. > Personally, I'd rather have createContext: taking a crossplatform > pixel/buffer format as argument, the platform context transcribe that into > the native object needed as parameter for context creation, and some sort of > way to check if the context created actually matched your specification. > Makes the whole "Your context was invalid for those operations" class of > errors a lot more transparent, which I've found to be the source of trouble > multiple times at least. > > Cheers, > Henry > -- Best regards, Igor Stasenko.

Dec. 9, 2011

Re: [Pharo-project] NBOpenGL

by Henrik Sperre Johansen

On 09.12.2011 11:27, Henrik Sperre Johansen wrote: > > That's not specific to offscreen rendering contexts though, (nor > pixelformats, another windows artifact) I should perhaps say; they're not Windows specific as such, but the implementation in NBOpenGL is. Personally, I'd rather have createContext: taking a crossplatform pixel/buffer format as argument, the platform context transcribe that into the native object needed as parameter for context creation, and some sort of way to check if the context created actually matched your specification. Makes the whole "Your context was invalid for those operations" class of errors a lot more transparent, which I've found to be the source of trouble multiple times at least. Cheers, Henry

Dec. 9, 2011

Re: [Pharo-project] NBOpenGL

by Henrik Sperre Johansen

On 09.12.2011 10:56, Fernando Olivero wrote: > the formatting of the "uml" is wrong! > > On Fri, Dec 9, 2011 at 10:46 AM, fernando.olivero(a)usi.ch > <fernando.olivero(a)usi.ch> wrote: >> Hi Igor, i have a question regarding the design of NBOpenGL. >> >> Why does the following offscreen method, deals with windows? >> >> NBOffscreenDisplay>>createOpenGLContext >> ctx := NBHostWindowContext createSpecificForPlatform. >> ctx createWindow: extent. >> ctx createContext: ctx defaultPixelFormat. >> >> I'm trying to include in the framework, support for MacOSX, starting >> with offscreen drawables support using CGL, therefore i would like to >> modify it to: >> >> >> NBOffscreenDisplay>>createOpenGLContext >> ctx := NBDisplayContext createSpecificForPlatform. >> ctx createContext: ctx defaultPixelFormat. >> >> >> NBGLDisplay >> >> NBDisplayContext >> NBOffscreenDisplay NBWindowedDisplay >> NBWinContext NBUnixContext >> NBMacOSXContext >> >> >> What do you think? >> Fernando >> WGL (Windows api for creating contexts) does not allow recreating contexts for exisiting windows, so you have to make a new window (and destroy it after if you don't intend to use it), just to get a new context with different capabilities. That's not specific to offscreen rendering contexts though, (nor pixelformats, another windows artifact) but creating contexts on windows, so it probably could/should/must be refactored when moving to multi-platform. TLDR; You'd break it on windows just removing that line. Cheers, Henry

Dec. 9, 2011

[Pharo-project] NativeBoost and C++ libraries

by Pavel Krivanek

Hi Igor, do you have some experiences with NativeBoost bindings to C++ libraries (with classes)? I have seen that Ruby has some interface generators for that purpose (Rice, rb++). Cheers, -- Pavel

Dec. 9, 2011

Re: [Pharo-project] NBOpenGL

by Fernando Olivero

the formatting of the "uml" is wrong! On Fri, Dec 9, 2011 at 10:46 AM, fernando.olivero(a)usi.ch <fernando.olivero(a)usi.ch> wrote: > Hi Igor, i have a question regarding the design of NBOpenGL. > > Why does the following offscreen method, deals with windows? > > NBOffscreenDisplay >>createOpenGLContext > Â Â Â Â ctx := NBHostWindowContext createSpecificForPlatform. > Â Â Â Â ctx createWindow: extent. > Â Â Â Â ctx createContext: ctx defaultPixelFormat. > > I'm trying to include in the framework, support for MacOSX, starting > with offscreen drawables support using CGL, therefore i would like to > modify it to: > > > NBOffscreenDisplay >>createOpenGLContext > Â Â Â Â ctx := NBDisplayContext createSpecificForPlatform. > Â Â Â Â ctx createContext: ctx defaultPixelFormat. > > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â NBGLDisplay > > NBDisplayContext > NBOffscreenDisplay Â Â Â Â Â Â Â Â Â Â NBWindowedDisplay > Â Â Â Â Â Â Â NBWinContext Â Â Â Â Â Â Â NBUnixContext > NBMacOSXContext > > > What do you think? > Fernando >

Dec. 9, 2011

[Pharo-project] NBOpenGL

by Fernando Olivero

Hi Igor, i have a question regarding the design of NBOpenGL. Why does the following offscreen method, deals with windows? NBOffscreenDisplay >>createOpenGLContext ctx := NBHostWindowContext createSpecificForPlatform. ctx createWindow: extent. ctx createContext: ctx defaultPixelFormat. I'm trying to include in the framework, support for MacOSX, starting with offscreen drawables support using CGL, therefore i would like to modify it to: NBOffscreenDisplay >>createOpenGLContext ctx := NBDisplayContext createSpecificForPlatform. ctx createContext: ctx defaultPixelFormat. NBGLDisplay NBDisplayContext NBOffscreenDisplay NBWindowedDisplay NBWinContext NBUnixContext NBMacOSXContext What do you think? Fernando

Dec. 9, 2011

Re: [Pharo-project] Help: Zodiac secure server.

by Sven Van Caekenberghe

Hi Prasad, On 08 Dec 2011, at 18:09, Prasad Khurd wrote: > Hello Sven, > I am trying to write a zodiac secure server. I was able to successfully make a server copying most of the server part from Zinc Http server. Then, I tried replacing the SocketStream with your ZnSecureSocketStream but that didnât workâ¦ I havenât read much on SSL yet so I assumed whatever was sent from the secure stream of the client would be decrypted on the server using ZnSecureSocketStream â like a toggle mostly but I guess I am wrong. Iâd appreciate it if you could give me some pointers or if you had a sample of such a secure server implementation. > > Thank you, > Prasad Thanks a lot for your interest in Zn+Zdc, this is a good area to work on. I haven't done this myself yet, for a couple of reasons: - lack of time - debugging Zdc was higher priority - client side was/is higher priority That being said, it would be nice if you could do a proof of concept. To make this work you have to do wrap a ZdcSecureSocketStream on: the socket that you get back from #waitForAcceptFor: The place to do this is in ZnSingleThreadedServer>>#socketStreamOn: It would be best to do this in a subclass from either ZnSingleThreadedServer or ZnMultiThreadedServer Then you have to set the server certificate on the stream by getting the #sslSession from the ZdcSecureSocketStream that you just created and calling #certificateName: (this won't work on Mac OS X due to missing functionality in the plugin). Finally you should do a #accept on the ZdcSecureSocketStream, if that works, the server should work transparently with the secure stream as if it is a regular one. Apart from debugging, there is no reason this should not work ;-) Good luck and please let me know how it goes! Regards, Sven

Dec. 9, 2011

Re: [Pharo-project] A possible bug in GZip streams

by StÃ©phane Ducasse

Tx! On Dec 8, 2011, at 8:38 PM, Martin Dias wrote: > > > On Thu, Dec 8, 2011 at 2:50 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 08 Dec 2011, at 18:43, Martin Dias wrote: > > > I think the problem is that this method supposes n >= 1: > > Yeah, that is why I propose a guard, maybe in this method > > n = 0 ifTrue: [ ^ buffer] > > thanks, it fixes the issue (inserted at the beginning of InflateStream>>next:into:startingAt:). > > The same issue should happen sending InflateStream>>readInto:startingAt:count: > > I guess we should add some tests in CompressionTests package. I can do it on a couple of days. > > > > but I have no time to analyze the consequences/implications. > > Sven > > > >

Dec. 9, 2011

[Pharo-project] Sprint friday 16 @ lille

by StÃ©phane Ducasse

Hi guys I'm not sure that my message passed in the mailing-list. We will organize a sprint new friday and everybody is welcome. Just let us know so that we prepare the rooms. Stef

Dec. 9, 2011