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

[Pharo-project] Pharo 1.3 - Build # 24 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 23, 2012

[Pharo-project] NBOpenGL issue with latest 1.4 Pharo image and latest NBCog VM

by Lawson English

I procure the latest and greatest of each of the components: NBCog, Pharo 1.4.image Pharo 1.4.changes etc I procure the latest CofigurationOfNBOpenGL from: MCHttpRepository location: 'http://www.squeaksource.com/NBOpenGL' user: '' password: ''. I run the following in a workspace: ConfigurationOfNBOpenGL project lastVersion load. NBInstaller install. Now, when I evaluate: GLTTRenderingDemo new OpenInWorld. Pharo hangs. cmd+. doesn't interrupt. Sigh.... Lawson

March 23, 2012

Re: [Pharo-project] About 1.4 Release...

by Schwab,Wilhelm K

Yearly seems a little slow, but might be about right to allow lots of time for testing. There will always be Jenkins for those who need a fix (sometimes guilty myself). Bug fix releases would be appreciated. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Yanni Chiu [yanni(a)rogers.com] Sent: Friday, March 23, 2012 11:10 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... On 23/03/12 5:34 AM, Marcus Denker wrote: > > Is that what we want? or will people say "without refactorings, I will not use it?" I think the release needs to happen soon, so we can all have a new baseline. According to the Pharo consortium vision doc, the release plan (maybe not for 1.4, but in the future) is to become yearly with two bug fix releases. If this were in place, then "refactoring" would miss the boat. Is it a big enough item to delay a release? Personally, I use it if it's in the image, and miss it slightly if it's not there. That's because I often work on a stripped down image, so others may feel differently.

March 23, 2012

Re: [Pharo-project] direct object manipulation

by Stan Shepherd

Hi Francisco, another possibility is the Scaffolding port by Yanni Chui - see thread http://forum.world.st/Magritte-import-an-existing-project-td1588263.html#a1… Video of Gerhard Obermann's port to Gemstone here: http://vimeo.com/2231019 Cheers, ...Stan -- View this message in context: http://forum.world.st/direct-object-manipulation-tp4494255p4499294.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 23, 2012

Re: [Pharo-project] About 1.4 Release...

by Schwab,Wilhelm K

Stef, I'm not finding faults - merely encouraging good energy. For now, I am nudging a polymorph-friendly MVP framework (presenters as morph-model factories) and cleaning my GSL interface. The latter has to be done carefully, because I can't have GPL preventing me from commercial use of some of my more specialized consumers of its services. Sadly, that will limit what I can release, but I hope to provide something that will allow anyone to grab the library, install my packages (and probably a custom library to compensate for missing features and load problems on Linux), and do a lot with it. Re linux, it ships as two libraries, neither of which will load (dynamically) on its own over dependencies. They know about it, and don't seem to care. 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: Friday, March 23, 2012 8:21 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... I'm working on cleaning ECompletion: now it works well in 1.4 So I guess that loading RBEngine and OB should make it. Now people should help. For 1.5 we will get nautilus. Stef > Ok, but that kind volunteer needs an image built the way they are told to do so. The convenience factor of having big stuff loaded into an image will attract users/testers. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shearar(a)gmail.com] > Sent: Friday, March 23, 2012 6:25 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] About 1.4 Release... > > On 23 March 2012 09:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> We were discussing here about the 1.4 release... and my standpoint is: >> >> "What is on the Build Server will be the Release" >> >> For 1.4, this means that this image is the release image: >> >> https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifac… >> >> possibly with more bugs fixed. >> >> the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 >> >> It especially means that we will not load additional packages (RB, OB....), because then we should >> have used the resulting image already the last months and we did not. >> >> Is that what we want? or will people say "without refactorings, I will not use it?" > > I'd say "What is on the Build Server will be the Release" is exactly > the right thing to do, because it's the thing you've been testing. You > can have high confidence that the artifact will be stable, etc. Adding > in extra stuff increases the testing burden. > > Of course, you (you, or some kind volunteer) could have a job that > adds the various extras, and tests that Pharo+(stuff) image. > > frank > >

March 23, 2012

Re: [Pharo-project] About 1.4 Release...

by Yanni Chiu

On 23/03/12 5:34 AM, Marcus Denker wrote: > > Is that what we want? or will people say "without refactorings, I will not use it?" I think the release needs to happen soon, so we can all have a new baseline. According to the Pharo consortium vision doc, the release plan (maybe not for 1.4, but in the future) is to become yearly with two bug fix releases. If this were in place, then "refactoring" would miss the boat. Is it a big enough item to delay a release? Personally, I use it if it's in the image, and miss it slightly if it's not there. That's because I often work on a stripped down image, so others may feel differently.

March 23, 2012

[Pharo-project] Pharo 1.4 Tests-Mac - Build # 287 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 23, 2012

[Pharo-project] block rewriting...

by StÃ©phane Ducasse

Begin forwarded message: > From: Paul Baumann <paul.baumann(a)theice.com> > Subject: Re: [vwnc] [vw7.7] Perhaps unknown limitation of BlockClosure>>once (in Assets) > Date: March 23, 2012 3:12:40 PM GMT+01:00 > To: Eliot Miranda <eliot.miranda(a)gmail.com>, Reinout Heeck <vwnclist(a)soops.nl> > Cc: "vwnc(a)cs.uiuc.edu" <vwnc(a)cs.uiuc.edu> > > It sounds similar to a technique I use in GS/S code to turn ComplexBlocks into SimpleBlocks (different terminology from VW, but same idea). The "Efficient GemStone Enumeration" framework has been enhanced and simplified (http://techsupport.gemstone.com/entries/175923-efficient-gemstone-enumerati…) Sorry I haven't shared the updated version yet. One of the neat things about the new version is that it is extended to optimize blocks for enumeration. It effectively recompiles blocks to pass context into simpler blocks through extended arguments rather than having a block closure reference external context. The optimized blocks are cached for reuse. Amazing gains are achieved in GS by using SimpleBlocks instead of ComplexBlocks. The framework I mentioned makes it possible to write application code to use simple blocks but it is still up to a developer to revise code to use the simple blocks. Developers get it wrong. They sometimes go through a lot of effort to refactor code but make a mistake in the optimization that makes all that work moot. This automatic optimization eliminates those mistakes and existing code can become much faster without having to tune application code. > > Collection>>including: including1 including: including2 > collect: threeArgBlock > "Extension of GS_CollectionPerformanceBase. plb 2011.06.27" > > | results optimizedBlock | > optimizedBlock := threeArgBlock forEnumerating: self. > results := self _newCollectResultForBlock: optimizedBlock. > self > _into: results > elective: including1 > elective: including2 > elective: nil > elective: nil > keyedCollect: optimizedBlock. > self _finishedCollect: optimizedBlock > started: 0 > results: results. > ^results > > This framework is for GS/S; however, the same performance gains can be obtained in other dialects. > > Paul Baumann > > > > From: vwnc-bounces(a)cs.uiuc.edu [mailto:vwnc-bounces@cs.uiuc.edu] On Behalf Of Eliot Miranda > Sent: Thursday, March 22, 2012 18:02 > To: Reinout Heeck > Cc: vwnc(a)cs.uiuc.edu > Subject: Re: [vwnc] [vw7.7] Perhaps unknown limitation of BlockClosure>>once (in Assets) > > > > On Thu, Mar 22, 2012 at 10:13 AM, Reinout Heeck <vwnclist(a)soops.nl> wrote: > Trying to atone for that foot in my mouth, I concocted a sketch for fixing #once. > > Clever! And that suggests a simple implementation for Squeak. Methods can maintain a map in a their properties/pragmas/method tags to map closure initial pc to cached value. Thanks!! > > Please find attached a workspace snippet that will alter the system without immediately crashing it. > When evaluating the script it will complain about undeclared names, simply hit 'leave undeclared'. > > > This implementation delegates the caching and becoming to the CompiledBlock instances instead of the BlockClosure instances that the original used. It should now work for both clean and copying blocks. > The simple test Steven Kelly supplied below should now yield true in both cases. > > This code has hardly been tested, its just a sketch and needs some cleanup (and it is developed on 771 FTW). > > In both the original and new versions I miss the flushing of the VM (JIT) caches, > could someone here with knowledge about the JIT review this apparent omission? > > > > On 3/21/2012 1:32 PM, Steven Kelly wrote: > Object class>>onceClean > "self onceClean == self onceClean" "true" > ^[Object new] once > > Object class>>onceUnclean > "self onceUnclean == self onceUnclean" "false" > ^[self new] once > > Enjoy, Reinout > > > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > > -- > best, > Eliot > > > This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

March 23, 2012

[Pharo-project] Pharo 1.4 Tests-Unix - Build # 302 - Still Unstable!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

March 23, 2012

[Pharo-project] [update 1.4] #14408

by Marcus Denker

14408 ----- Issue 5525: Get rid of string comparison in MessageListBrowser and FlatMessageListBrowser http://code.google.com/p/pharo/issues/detail?id=5525 Issue 5524: StartupPreferences progress bar http://code.google.com/p/pharo/issues/detail?id=5524 -- Marcus Denker -- http://marcusdenker.de

March 23, 2012