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

[Pharo-project] Zodiac - 2nd delivery - A new (binary) secure socket stream + Zn clients doing HTTPS

by Sven Van Caekenberghe

Hi, Here is the second delivery of Zodiac: A new (binary) secure socket stream and the ability of the Zinc HTTP Components clients to do HTTPS. Warning: this is of course not yet code for general consumption, use the source and the comments. This is a proof of concept. ZdcSecureSocketStream, a subclass of ZdcOptimizedSocketStream was added. This implementation works together with both a Socket and with a ZdcAbstractSSLSession object, of which there is currently one implementation, ZdcPluginSSLSession. Loading this code is safe, to make it work though, you need to add a plugin to your VM. Please go to http://code.google.com/p/squeakssl/ and download the apropriate plugin for your platform and put it next to the other plugins. Disclaimer: I only tested on Mac OS X, but the plugin should work on the other platforms. The Smalltalk code works on Pharo 1.2 and 1.3 as well as on Squeak 4.2 with any modifications. There is currently just one simple test in Zodiac itself. What is nicer though, is the fact the Zinc HTTP Components clients can now do HTTPS ! Load the latest version of Zinc-Zodiac from the ZincHTTPComponents repository and enable the socket stream factory: ZnNetworkingUtils default: ZnZodiacNetworkingUtils new. Tada: you should now be able to do any of the following ZnClient get: 'https://encrypted.google.com/search?q=Smalltalk' ZnHttpClient new get: 'https://www.gmail.com' ZnHttpClient new get: 'https://secure.wikimedia.org/' ZnHttpClient new get: 'http://gforge.inria.fr/frs/?group_id=1299' ZnHttpClient new get: 'https://www.paypal.com' ZnClient get: 'https://aws.amazon.com/' These are all part of ZnHTTPSTests. (The difference between ZnClient and ZnHttpClient is that the latter has more options, follows redirects, deals with cookies, ..). When you have Zinc-Patch-HTTPSocket loaded (which is the case in Pharo 1.3 Core and derivatives) the legacy interface will work as well: HTTPSocket httpGet: 'https://encrypted.google.com/search?q=Smalltalk' Please note that certificate management or checking the server's certificate or hostname is not yet supported. There will probably be many use cases that give errors. If you have examples that I can easily reproduce, please let me know. There is still a good way to go, but I think this is an important step. Sven

May 18, 2011

Re: [Pharo-project] [Vm-dev] Re: out of memory - cog on windows

by Levente Uzonyi

On Wed, 18 May 2011, Tudor Girba wrote: > > Hi, > > On 18 May 2011, at 16:30, Levente Uzonyi wrote: > >> On Wed, 18 May 2011, Tudor Girba wrote: >> >>> >>> Hi, >>> >>> Is there a possibility to have any sort of answer on this topic? >>> >>> It looks to me like this bug is critical given that it prevents us to work with images larger than some 200M. >> >> IMHO it's a problem on the image side. Change the behavior of #lowSpaceWatcher to fix the problem. > > How would you do it? :) According to Igor's mail, the UI process is suspended by the low space watcher, which prevents you from seeing the cause of the problem. So, for example you could wake up the UI process if that was suspended by the VM and/or log some info about the situation. This won't save your image, but since it works on non-windows VMs, that's not a problem. > > And if it is an image problem, why does it only appear on Windows? Are you using the same VMs (interpreter/cog, version number matches, etc)? If you didn't try so far, then open the image with the latest interpreter VM on windows, it has some extra checks for allocations which is not implemented in Cog yet. Levente > > > Cheers, > Doru > > > >> >> Levente >> >>> >>> Cheers, >>> Tudor >>> >>> >>> >>> On 16 May 2011, at 11:06, Tudor Girba wrote: >>> >>>> Hi Igor, >>>> >>>> Thanks a lot for looking into this. For us (around Moose), this is a critical issue because we play with our models in memory and regularly have images of several hundred megabytes. While most of us work on Mac without a problem, some other people work on Windows and this is a bottleneck. >>>> >>>> Unfortunately, I do not have enough know-how to dive into the VM, but I would be gladly help in any way I can. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 16 May 2011, at 10:50, Igor Stasenko wrote: >>>> >>>>> On 10 May 2011 09:34, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I am back with some more input on the matter. We played with it, and found that basically any image that goes beyond something like 200MB limit (or maybe it's the number of objects), will not open on Windows. >>>>>> >>>>>> I would need some help on this. Has nobody else hit this wall, or is it that I am doing something wrong? >>>>>> >>>>>> One scenario that we used to reproduce the problem looks like this: >>>>>> 1. Take a Moose image: >>>>>> http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… >>>>>> 2. Run: >>>>>> 1 to: 3 do: [ :i | MooseScripts createModelForConfigurationOfMoose ] >>>>>> This will basically create some 850000 objects and will get the image to some 400+MB >>>>>> 3. Save and quit the image >>>>>> 4. Reopen it >>>>>> >>>>>> A ready-made image with the result of this can be found here: >>>>>> http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip >>>>>> >>>>>> This works well on Mac, but on Windows when you reopen the image, you get the out of memory message. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>> >>>>> I using latest VMs built by cmake on windows, and everytime i run this image, >>>>> it opens a 'Space is low' dialog and then image not reacting on anything. >>>>> VM not crashing however and responds to windows events.. But because >>>>> UI process is broken >>>>> an image simply not reacts to anything. >>>>> >>>>> >>>>> I think that the problem is that this dialog are shown at early image >>>>> startup time, >>>>> before everything is properly initialized, and because of that UI >>>>> stalls somewhere. >>>>> >>>>> >>>>> Next things which i tried is to increase a virtual memory limit in >>>>> sqWin32Alloc.h >>>>> >>>>> #ifndef MAX_VIRTUAL_MEMORY >>>>> #define MAX_VIRTUAL_MEMORY 512*1024*1024 >>>>> #endif >>>>> >>>>> first i raised it to 768 Mbytes.. same behavior. >>>>> then i raised it to 1Gb and again same behavior.. >>>>> >>>>> So, either this constant is overridden somewhere or it actually >>>>> doesn't affecting the low-space detection mechanism as i would expect. >>>>> Any suggestions? >>>>> >>>>> >>>>> I will continue looking , what happens on VM side, >>>>> but in addition to that, i think we should do something on image side as well: >>>>> - a low space watcher should not pop up before passing image startup, >>>>> because if preempted process is UI process (and in 99.99% cases it is), >>>>> then it means that low space watcher blocks UI process and as a consequence, >>>>> your image stops handling events. >>>>> >>>>> >>>>> Also, i thinking about different approach for signaling a low space condition. >>>>> Instead of signaling a low space semaphore, what VM could do is to >>>>> fail an allocation primitive >>>>> and set the error code to "low memory warning" >>>>> then a primitive failure code could actually throw an exception, which >>>>> then could be handled as usual... >>>>> so you could write a code, like: >>>>> >>>>> [ self allocateSomethingReallyHuge ] on: LowMemoryWarning do: [:err | >>>>> self shouldWeReallyCare ifFalse: [ self tellVMThatItsOk. err resume ] >>>>> ifTrue: [ err pass ] >>>>> ] >>>>> >>>>> Because by preempting a currently active process, which "possibly" >>>>> causing a memory problems is not a solution, >>>>> as you can see, if it happens during startup phase, then you it just >>>>> stucks and image hangs. >>>>> But if we could use exceptions, we could just ignore this warning (or >>>>> do something else) during image startup, >>>>> instead of blocking UI process , showing a useless popup message and >>>>> letting image hang like that. >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "If you interrupt the barber while he is cutting your hair, >>>> you will end up with a messy haircut." >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Obvious things are difficult to teach." >>> >>> >>> >>> > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > >

May 18, 2011

Re: [Pharo-project] Circle is gone

by Alexandre Bergel

There is no user of these classes in a 1.2. And nobody shouted against its removal. This was a reason good enough to remove them :-) Alexandre On 18 May 2011, at 10:36, Tudor Girba wrote: > I guess there was a reason behind removing them, and I also guess that the best way would be to find what is the other preferred solution besides adding them back :). Or was there removal a mistake? > > Cheers, > Doru > > > On 18 May 2011, at 16:08, Alexandre Bergel wrote: > >> I also bumped into the same problem. For the case of Mondrian, I will copy the missing classes into Mondrian. >> These classes were removed quite some times ago from Pharo 1.3 >> >> Cheers, >> Alexandre >> >> >> On 18 May 2011, at 08:54, Tudor Girba wrote: >> >>> Hi, >>> >>> Circle seems to be gone from Pharo 1.3. >>> >>> What is now the preferred way to specify a circle? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "When people care, great things can happen." >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 18, 2011

Re: [Pharo-project] Circle is gone

by Tudor Girba

I guess there was a reason behind removing them, and I also guess that the best way would be to find what is the other preferred solution besides adding them back :). Or was there removal a mistake? Cheers, Doru On 18 May 2011, at 16:08, Alexandre Bergel wrote: > I also bumped into the same problem. For the case of Mondrian, I will copy the missing classes into Mondrian. > These classes were removed quite some times ago from Pharo 1.3 > > Cheers, > Alexandre > > > On 18 May 2011, at 08:54, Tudor Girba wrote: > >> Hi, >> >> Circle seems to be gone from Pharo 1.3. >> >> What is now the preferred way to specify a circle? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "When people care, great things can happen." >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

May 18, 2011

Re: [Pharo-project] [Vm-dev] Re: out of memory - cog on windows

by Tudor Girba

Hi, On 18 May 2011, at 16:30, Levente Uzonyi wrote: > On Wed, 18 May 2011, Tudor Girba wrote: > >> >> Hi, >> >> Is there a possibility to have any sort of answer on this topic? >> >> It looks to me like this bug is critical given that it prevents us to work with images larger than some 200M. > > IMHO it's a problem on the image side. Change the behavior of #lowSpaceWatcher to fix the problem. How would you do it? :) And if it is an image problem, why does it only appear on Windows? Cheers, Doru > > Levente > >> >> Cheers, >> Tudor >> >> >> >> On 16 May 2011, at 11:06, Tudor Girba wrote: >> >>> Hi Igor, >>> >>> Thanks a lot for looking into this. For us (around Moose), this is a critical issue because we play with our models in memory and regularly have images of several hundred megabytes. While most of us work on Mac without a problem, some other people work on Windows and this is a bottleneck. >>> >>> Unfortunately, I do not have enough know-how to dive into the VM, but I would be gladly help in any way I can. >>> >>> Cheers, >>> Doru >>> >>> >>> On 16 May 2011, at 10:50, Igor Stasenko wrote: >>> >>>> On 10 May 2011 09:34, Tudor Girba <tudor.girba(a)gmail.com> wrote: >>>>> Hi, >>>>> >>>>> I am back with some more input on the matter. We played with it, and found that basically any image that goes beyond something like 200MB limit (or maybe it's the number of objects), will not open on Windows. >>>>> >>>>> I would need some help on this. Has nobody else hit this wall, or is it that I am doing something wrong? >>>>> >>>>> One scenario that we used to reproduce the problem looks like this: >>>>> 1. Take a Moose image: >>>>> http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/… >>>>> 2. Run: >>>>> 1 to: 3 do: [ :i | MooseScripts createModelForConfigurationOfMoose ] >>>>> This will basically create some 850000 objects and will get the image to some 400+MB >>>>> 3. Save and quit the image >>>>> 4. Reopen it >>>>> >>>>> A ready-made image with the result of this can be found here: >>>>> http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip >>>>> >>>>> This works well on Mac, but on Windows when you reopen the image, you get the out of memory message. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>> >>>> I using latest VMs built by cmake on windows, and everytime i run this image, >>>> it opens a 'Space is low' dialog and then image not reacting on anything. >>>> VM not crashing however and responds to windows events.. But because >>>> UI process is broken >>>> an image simply not reacts to anything. >>>> >>>> >>>> I think that the problem is that this dialog are shown at early image >>>> startup time, >>>> before everything is properly initialized, and because of that UI >>>> stalls somewhere. >>>> >>>> >>>> Next things which i tried is to increase a virtual memory limit in >>>> sqWin32Alloc.h >>>> >>>> #ifndef MAX_VIRTUAL_MEMORY >>>> #define MAX_VIRTUAL_MEMORY 512*1024*1024 >>>> #endif >>>> >>>> first i raised it to 768 Mbytes.. same behavior. >>>> then i raised it to 1Gb and again same behavior.. >>>> >>>> So, either this constant is overridden somewhere or it actually >>>> doesn't affecting the low-space detection mechanism as i would expect. >>>> Any suggestions? >>>> >>>> >>>> I will continue looking , what happens on VM side, >>>> but in addition to that, i think we should do something on image side as well: >>>> - a low space watcher should not pop up before passing image startup, >>>> because if preempted process is UI process (and in 99.99% cases it is), >>>> then it means that low space watcher blocks UI process and as a consequence, >>>> your image stops handling events. >>>> >>>> >>>> Also, i thinking about different approach for signaling a low space condition. >>>> Instead of signaling a low space semaphore, what VM could do is to >>>> fail an allocation primitive >>>> and set the error code to "low memory warning" >>>> then a primitive failure code could actually throw an exception, which >>>> then could be handled as usual... >>>> so you could write a code, like: >>>> >>>> [ self allocateSomethingReallyHuge ] on: LowMemoryWarning do: [:err | >>>> self shouldWeReallyCare ifFalse: [ self tellVMThatItsOk. err resume ] >>>> ifTrue: [ err pass ] >>>> ] >>>> >>>> Because by preempting a currently active process, which "possibly" >>>> causing a memory problems is not a solution, >>>> as you can see, if it happens during startup phase, then you it just >>>> stucks and image hangs. >>>> But if we could use exceptions, we could just ignore this warning (or >>>> do something else) during image startup, >>>> instead of blocking UI process , showing a useless popup message and >>>> letting image hang like that. >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>> >>> -- >>> www.tudorgirba.com >>> >>> "If you interrupt the barber while he is cutting your hair, >>> you will end up with a messy haircut." >>> >> >> -- >> www.tudorgirba.com >> >> "Obvious things are difficult to teach." >> >> >> >> -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

May 18, 2011

Re: [Pharo-project] OCompletion?

by Alexandre Bergel

> In which Pharo? 1.3? I do not seem to bump into it. In what context do you get it? When I try to edit code within a debugger. It does not systematically appear. Just once in a while. Alexandre > > > On 18 May 2011, at 16:19, Alexandre Bergel wrote: > >> Hi! >> >> Am I the only one to bump all the time into error raised by OCompletion? >> >> in OController>>handleKeystrokeBefore: kbEvent editor: theEditor >> I just switched: >> self isMenuOpen ifFalse: [ self openMenuFor: theEditor ]. >> >> into: >> self isMenuOpen ifFalse: [ [self openMenuFor: theEditor] on: Error do: [] ]. >> >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 18, 2011

Re: [Pharo-project] OCompletion?

by Tudor Girba

Hi, In which Pharo? 1.3? I do not seem to bump into it. In what context do you get it? Cheers, Doru On 18 May 2011, at 16:19, Alexandre Bergel wrote: > Hi! > > Am I the only one to bump all the time into error raised by OCompletion? > > in OController>>handleKeystrokeBefore: kbEvent editor: theEditor > I just switched: > self isMenuOpen ifFalse: [ self openMenuFor: theEditor ]. > > into: > self isMenuOpen ifFalse: [ [self openMenuFor: theEditor] on: Error do: [] ]. > > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

May 18, 2011

[Pharo-project] OCompletion?

by Alexandre Bergel

Hi! Am I the only one to bump all the time into error raised by OCompletion? in OController>>handleKeystrokeBefore: kbEvent editor: theEditor I just switched: self isMenuOpen ifFalse: [ self openMenuFor: theEditor ]. into: self isMenuOpen ifFalse: [ [self openMenuFor: theEditor] on: Error do: [] ]. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 18, 2011

Re: [Pharo-project] Circle is gone

by Alexandre Bergel

I also bumped into the same problem. For the case of Mondrian, I will copy the missing classes into Mondrian. These classes were removed quite some times ago from Pharo 1.3 Cheers, Alexandre On 18 May 2011, at 08:54, Tudor Girba wrote: > Hi, > > Circle seems to be gone from Pharo 1.3. > > What is now the preferred way to specify a circle? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 18, 2011

Re: [Pharo-project] Basic tricks for improving a serializer?

by Henrik Sperre Johansen

On 18.05.2011 14:53, Sven Van Caekenberghe wrote: > Mariano, > > On 18 May 2011, at 14:29, Mariano Martinez Peck wrote: > >> Sven, I improved quite a lot using your buffered write stream. >> What I don't understans is why MultiByteFileStream doesn't perform as good as them. >> If I see StandardFileStream has an internal buffer called 'buffer1'. >> >> So why is that much difference between using MultiByteFileStream directly and >> a WriteStream (ByteArray new writeSteam ) or ZnBufferedWriteStream ? Because actually writing to file is expensive. MBFS does it on every nextPut/nextPutAll: send, ZnBuffered only when asked to/buffer fills. > I just looked briefly at the hierarchy, it seems that buffer1 is an output buffer of size 1 ! > > Have a look at > > StandardFileStream>>#nextPut: char > "Write the given character to this file." > > rwmode ifFalse: [^ self error: 'Cannot write a read-only file']. > collection ifNotNil: [ > position< readLimit ifTrue: [ self flushReadBuffer ] ]. > buffer1 at: 1 put: char. > self primWrite: fileID from: buffer1 startingAt: 1 count: 1. > ^ char > > There is simply no buffering going on. > buffer1 is a mystery to me ;-) > > Sven The primitive requires an object of variableByte type. If you didn't have a buffer1, you'd need to create a new 1-element ByteArray/String on every call to nextPut: ;) As for the primitive call always flushing to file, that is a decision which have arguments both in favor and against it. I wasn't there when it was written, so have no idea why they weighed one over the other. If I were to guess, I'd say PLS ("But I wrote it to file! Why isnt it there yet when I open it??") and deterministic behaviour won over performance. Changing it now would probably mean quite a few changes to f.ex. source management if you want the same level of recoverability you are ensured now. That does not mean a buffering of write stream should not be available, of course. There are so many ways to do that though it quickly turns into painting a bikeshed. Cheers, Henry

May 18, 2011