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

[Pharo-project] squeaksource is down :(

by Mariano Martinez Peck

Thanks -- Mariano http://marianopeck.wordpress.com

May 16, 2011

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

by Igor Stasenko

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.

May 16, 2011

[Pharo-project] [Hudson] update

by Marcus Denker

-> 1.2 and 1.3 (both core and Full) are on the way to be green at the same time for the first time. -> We added some projects to the TaskForces: Ring: https://pharo-ic.lille.inria.fr/hudson/job/Ring/ A new Meta Model for code Fuel: https://pharo-ic.lille.inria.fr/hudson/job/Fuel/ Serializer Nautilus: https://pharo-ic.lille.inria.fr/hudson/job/Nautilus/ Browser Nile: https://pharo-ic.lille.inria.fr/hudson/job/Nile/ Streams, rewritten with Traits (used to be part of Full, parked here until we have manpower to look at it and push it...) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 16, 2011

Re: [Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

by Nicolas Cellier

2011/5/16 David T. Lewis <lewis(a)mail.msen.com>: > On Sat, May 14, 2011 at 01:13:29PM +0200, Nicolas Cellier wrote: >> 2011/5/14 St?phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> >> >> >> >> I accelerated raisedTo:modulo: a bit with a primitive >> >> (http://bugs.squeak.org/view.php?id=7120) but that's not enough >> > Nicolas >> > >> > do you know why it was not integrated? >> > It is a good candidate to check the build system of the VM and their evolution. >> > Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins. >> > >> > Stef >> > >> >> Don't know. > > Nicolas, > > I added your LargeIntegersPlugin>>primMontgomeryTimes:modulo:mInvModB: in > SqS/VMMaker/VMMaker-dtl.233 (interpreter VM only, not Cog), and added some > notes to http://bugs.squeak.org/view.php?id=7120. > > It compiles and runs correctly on both 32 and 64 bit platforms, but I > cannot confirm the performance gain, so examples or tests would be > helpful. > > On my system I built 32 and 64-bit versions, and I can confirm that the > primitive runs and that the results are as expected: > > Â 12345678907 raisedTo: 3 modulo: 12345678917 ==> 12345677917 > Â 12345678907 montgomeryRaisedTo: 3 modulo: 12345678917 ==> 12345677917 > > But performance is not good in the example I came up with. On an > interpreter VM (not Cog): > > Â Time millisecondsToRun: [100000 timesRepeat: [12345678907 raisedTo: 3 modulo: 12345678917]] ==> 633 > Â Time millisecondsToRun: [100000 timesRepeat: [12345678907 montgomeryRaisedTo: 3 modulo: 12345678917]] ==> 1415 > Yes, there is a little overhead at method startup, so if the power is small, there is no gain in using Montgomery. You must increase the power. Nonetheless, the results with classical VM were mitigated as I wrote in the mantis issue with kind of random performance gains. Note that the results are different with COG: Time millisecondsToRun: [100000 timesRepeat: [12345678907 raisedTo: 3 modulo: 12345678917]] ==> 508 Time millisecondsToRun: [100000 timesRepeat: [12345678907 montgomeryRaisedTo: 3 modulo: 12345678917]] ==> 646 And when we increase the power, Montgomery generally wins by about a factor 2: Time millisecondsToRun: [10000 timesRepeat: [12345678907 raisedTo: 30000 modulo: 12345678917]] ==> 534 Time millisecondsToRun: [10000 timesRepeat: [12345678907 montgomeryRaisedTo: 30000 modulo: 12345678917]] ==> 255 Nicolas >> >> Don't know. I also have my modest bitShift: improvments pending >> (http://bugs.squeak.org/view.php?id=7109) >> Maybe I haven't performed enough tests to assert the performance gain. >> The changes are reliable, I run a VM with both improvments without >> crash for months. > > I have not looked at http://bugs.squeak.org/view.php?id=7109 yet but > will do so. > > Dave > > >

May 16, 2011

Re: [Pharo-project] LAst Phato core, Zn and proxy [WAS] Re: 1.3-Core

by Sven Van Caekenberghe

Hi Mariano, On 16 May 2011, at 09:36, Mariano Martinez Peck wrote: > Hi. I didn't follow the long thread, but in latest PharoCore (when Zn is present) I cannot use monticello because I cannot get out. > I am behind a proxy but with the previous network library it worked out of the box. > > Is this the same problem of Alexandre? is there an issue in the bugtracket? can we integrated? > is there a workarround so that I can continue using my image? This should all be fixed, in the latest Zn, which should be integrated soon, but that I cannot do. You can always just load Zn from its official repository over what Core has. Sven

May 16, 2011

Re: [Pharo-project] Amazon AWS S3 Monticello Mirror

by Sven Van Caekenberghe

On 16 May 2011, at 09:25, Marcus Denker wrote: > Yes! We should get that setup... very nice! > > Whose Amazon Account do we use? Currently, the demo is on my AWS account (part of http://zn.stfx.eu) To set this up properly, I need an AWS account held by some official body. This requires a credit card. There will be costs for storage on S3, network transfers and some small (micro) EC2 instance running the syncing bot. Let's say we store 10GB, transfer 10GB each month, run 1 micro instance continuously, that would be close to $25 each month, $300 a year. Doubling to 20GB would add like $5 a month. A new AWS account gets 1 year of a micro instance and some storage/transfer for free, so the first year would be less. Maybe we should discuss this further off list. Sven

May 16, 2011

Re: [Pharo-project] [TODO] 1.3

by Mariano Martinez Peck

On Mon, May 16, 2011 at 9:15 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Core > ==== > > Open Issues: 20 > http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3 > Failing Tests: 1 > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… > > Full > === > Open Issues: 8 > > http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.3-DevImage > Failing Tests: 3 > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.3/lastCompletedBuild/t… > > I've removed XMLSupport so there are 2 less failing tests. > > => Most important next Issue to tackle: Get all tests green. > > It would be nice to get both Core and Full green. Than the idea is that in > the spirit of Continuous > Delivery, we just keep it green. No degeneration of trivial problems > (undeclards), fast roll-back of > problematic changes... > > The idea is to keep it in a state that we could, at a minumum, always say > "We could release next Friday". > And the best would be: "We could release today". > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Mariano http://marianopeck.wordpress.com

May 16, 2011

[Pharo-project] LAst Phato core, Zn and proxy [WAS] Re: 1.3-Core

by Mariano Martinez Peck

Hi. I didn't follow the long thread, but in latest PharoCore (when Zn is present) I cannot use monticello because I cannot get out. I am behind a proxy but with the previous network library it worked out of the box. Is this the same problem of Alexandre? is there an issue in the bugtracket? can we integrated? is there a workarround so that I can continue using my image? Thanks Mariano On Fri, May 13, 2011 at 3:43 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > I updated Zinc-HTTP and Zinc-Tests from your server. > Running the tests gives me: 151 run, 151 passes, 0 expected failures, 0 > failures, 0 errors, 0 unexpected passes > > Really cool! > > Alexandre > > On 13 May 2011, at 09:39, Sven Van Caekenberghe wrote: > > > > > On 13 May 2011, at 15:24, Alexandre Bergel wrote: > > > >> I use a core 13197. Running Zinc tests gives me: > >> 146 run, 118 passes, 0 expected failures, 28 failures, 0 errors, 0 > unexpected passes > > > > For all tests to pass, you need the very latest version (160) where the > proxy is bypassed for localhost. > > Also, make sure no other ZnServers are running (they would block the 1701 > port needed by the tests). > > > > Sven > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Mariano http://marianopeck.wordpress.com

May 16, 2011

Re: [Pharo-project] XML maintainer??? Fwd: [Pharo-bugtracker] Issue 4232 in pharo: Failing Tests in Full: XML

by Mariano Martinez Peck

Name: ConfigurationOfPharo-MarianoMartinezPeck.171 Author: MarianoMartinezPeck Time: 16 May 2011, 9:28:34 am UUID: 8425d056-6119-403e-aaf1-07078d6b294d Ancestors: ConfigurationOfPharo-MarianoMartinezPeck.170 XMLSupport was removed from PharoDev On Sun, May 15, 2011 at 11:14 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > So...we added XML to PharoDev. Where are the maintaners? Could you please > check these issues? > > Thanks! > > mariano > > ---------- Forwarded message ---------- > From: <pharo(a)googlecode.com> > Date: Sun, May 15, 2011 at 8:50 PM > Subject: [Pharo-bugtracker] Issue 4232 in pharo: Failing Tests in Full: XML > To: pharo-bugtracker(a)lists.gforge.inria.fr > > > Status: Accepted > Owner: marcus.d...(a)gmail.com > Labels: Milestone-1.3-DevImage > > New issue 4232 by marcus.d...(a)gmail.com: Failing Tests in Full: XML > http://code.google.com/p/pharo/issues/detail?id=4232 > > XML.Tests.Parser.Nodes.XMLObservableListTest.testReplaceFromToWithStartingAt >>>> 0.0 1 >>>> >>>> XML.Tests.Parser.Nodes.XMLOrderedListTest.testReplaceFromToWithStartingAt >>>> >>> > > _______________________________________________ > Pharo-bugtracker mailing list > Pharo-bugtracker(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

May 16, 2011

Re: [Pharo-project] Amazon AWS S3 Monticello Mirror

by Marcus Denker

On May 15, 2011, at 11:12 PM, StÃ©phane Ducasse wrote: > thanks this is an excellent initiative. > Marcus will love that. > Yes! We should get that setup... very nice! Whose Amazon Account do we use? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 16, 2011