December 2011 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] How to resurrect an unrepsonsive image?

by StÃ©phane Ducasse

On Dec 8, 2011, at 11:49 AM, Norbert Hartl wrote: > Trying to recover the image was not important for me but for pharo. I just liked to participate in solving a problem that is hard to debug. Thanks! Stef

Dec. 9, 2011

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

by Martin Dias

Hi Levente, On Thu, Dec 8, 2011 at 5:44 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 8 Dec 2011, 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. >> > > Yeah, that "fixes" the issue, but why didn't it fail before the "fix", > when there was only one string written and read? ;) > I don't understand what you mean. But I found something strange when debugging, maybe it's the heisenbug you mentioned before: | aStream zipStream | aStream := ByteArray new writeStream binary. zipStream := GZipWriteStream on: aStream. zipStream nextPut: 5. zipStream close. aStream close. aStream := aStream contents readStream binary. zipStream := GZipReadStream on: aStream. self halt. zipStream next inspect. zipStream close. aStream close. When the #halt happens, I just press "Proceed". One hopes that #next answers 5 but not nil as it actually answers. Do you have a link to the mentioned heisenbug description? MartÃn > > > Levente > > > >> >> >> but I have no time to analyze the consequences/implications. >>> >>> Sven >>> >>> >>> >>> >>> >> >

Dec. 9, 2011

[Pharo-project] [ANN] Magma 1.3

by Chris Muller

I am very pleased to announce the immediate availability of Magma 1.3. The following detail the major improvements to 1.3 over 1.2: Serializer Upgrade ==== BlockClosures (Contexts and CompiledMethods too, of course), can now be stored in the database, even with references to inst-vars, self, temps or globals. Split-Ordered Lists ==== Tom Rushworth developed a fantastic Split-Ordered list implementation for Squeak. Working closely with Tom, this package has been extended in Magma to support very large SOL collections, implemented as a MagmaSolHashTable. Thank you Tom! The MagmaSolHashTable is actually a fairly primitive collection, and was used as the basis for two new collections: A MagmaHashTable and a completely new implementation of MagmaDictionary which is much faster than the old one (almost as fast as a preallocated dictionary). Full Monticello Model ==== When using Magma as a Monticello repository the package versions are not zipped but stored directly in the repository as native instances of MCVersions, MCPackages, MCInfos, MCDefinitions, etc. All of these original MC object instances are canonicalized so there is only ONE copy of that MCMethodDefinition from 2002 which is shared rather than copied in every version since. MCPackages are also canonicalized, as is all ancestry! For packages stored in a Magma repository, two new menu options appear on the methods menu and classes menu: browse mc versions browse mc origin The first shows all versions of a particular method or class-definition across all MC versions saved to that repository, in chronological order (no latency). The second opens the MC-Version Inspector in which that version of the method was saved, to see the version notes. This is very useful for quickly knowing WHY changes were made. Note: Currently only Squeak has its IDE tools updated to support this. WriteBarrier Resurrection ==== After two years dormancy, Avi Bryant's original WriteBarrier has been resurrected for use in closure/Cog images. Its original dependency on NewCompiler has been removed. With both the WriteBarrier and Cog, the MagmaBenchmarker reports a new record maximum commit rate -- 456 commits per second !! The WriteBarrier is now on by default, so nothing needs to be done to enjoy the speed up. Proxy Transparency ==== A new extension to the WriteBarrier should now alleviate the need to send #yourself to primitive arguments! Primitives which require arguments are now overridden in the anonymous subclass so that the arguments will automatically be ensured to be fully-reified for the super call. Immutability ==== For performance, TimeSpans, Durations, DateAndTimes, Points, Intervals, Colors are now immutable. Strings are also immutable by default, but now a custom ImmutabilityStrategy may be specified, providing fine control over immutability in case mutable Strings are needed (or if other objects can be made immutable). Platform Independence ==== Magma 1.3 runs on Squeak 4.3 and Pharo 1.3. All of the packages have been renamed in accordance with contemporary package naming conventions employed by most other active Squeak and Pharo projects. Platform-specific behaviors are now in platform-specific packages (named with "-Squeak" or "-Pharo"). The package hierarchy is documented at http://wiki.squeak.org/squeak/6178. More ==== Many minor cleanups, fixes, and usability improvements. This is, by far, the best Magma ever. Please enjoy the new version. - Chris

Dec. 8, 2011