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

[Pharo-project] Suggestions about Nautilus Look

by Fabrizio Perin

Hi all, I have a couple of propositions about the Nautilus look: 1 - If the Nautilus browser is a package browser why an infinity stack of grey packages is shown? I think it is possible to safely remove all the grey package icons since they are not really useful nor meaningful. This will make the visual impact of nautilus lighter. 2- I think would be nicer to have smaller icons for tests like the one from omnibrowser. I understand the icons are like buttons but the active area to trigger the event "run the test" is not the icon itself, isn't it? It is more in the area around the icon (also these icons appear in strange places in the code, e.g. MooseModel>>add: which is weird). 3- The text in the message that appear in bottom-left corner that notify about the test results it is not really visible if the background is yellow or green so what about to make it black. Or better, what about to make it black if the background color is green or yellow and leave it white if the background is red? 4- the buttons to see the bytecode and the decompile code I immagine they can became useful for some particular development but for normal development I never had the needed to check the decompiled version of a method or the bytecode. Different matter are the buttons for the instance and class variables. It would be cool to make these functionalists less "visible" making them available in a different way, for example in the contextual menu that appear in the method editor panel. What do you think? Cheers, Fabrizio

May 24, 2012

[Pharo-project] [update 2.0] #20094

by Marcus Denker

20094 ----- Issue 5959: Failing test: SpecInterpreterTest>>testBuildWindowFor http://code.google.com/p/pharo/issues/detail?id=5959 Issue 5966: DropListMorph do not pop the list when the text field is clicked http://code.google.com/p/pharo/issues/detail?id=5966 -- Marcus Denker -- http://marcusdenker.de

May 24, 2012

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Sebastian Sastre

I agree with Henrik (both clarifications) For the record, the error happens with a surprising value in aSize. It happens when aSize is as low as 260 o.O sebastian o/ On May 24, 2012, at 5:33 AM, Henrik Sperre Johansen wrote: > On 23.05.2012 20:18, Sven Van Caekenberghe wrote: >> On 23 May 2012, at 19:48, Marcus Denker wrote: >> >>> No, the image as it is now just quits. Delayed our deployment of the ESUG registration server >>> for some weeks... normal seaside use, image quites after a day. >>> >>> It's far from obvious. >>> >>> I think the image should work out of the box. Why destinguish between deployment and development? >>> What is good in deployment is for sure gut in development. > It's the other way around in this case, what's good in development is not always so good in deployment. > In development, you want to be notified of issues as soon as possible. > If they still slip through to deployment, you want them dealt with as gracefully as possible. > > >> It might be a bit surprising, but I think Hendrik's reasoning is quite good: you don't want to keep on expanding when there are problems not freeing resources that are limited. A good server needs resource limits. >> >> We can discuss more tomorrowâ¦ >> >> Sven >> >> >> > Well, both that, and the fact it can't be done safely. > The process of increasing its size might lead to lost signals. > > 99% of the time, setting the size at startup to a larger value than the default (before anything but the input semaphore is registered) is a better approach than increasing automatically, and in the remaining 1% it is better to fix whatever application issue is causing semaphore leaks anyways. > > Cheers, > Henry >

May 24, 2012

Re: [Pharo-project] Pressed Morph feedback on PharoTheme

by Goubier Thierry

Le 24/05/2012 09:19, Goubier Thierry a Ã©crit : > Another bug shown with my change is, if you start to scroll with the > slider, it depresses correctly, but, as soon as you move outside the > bounds of the scrollbar, even while pressing the left mouse button, then > the slider goes back to the "not pressed" state while you are still > scrolling up or down. To correct that bug, a small change in ScrollBar>>mouseLeaveThumb: event redButtonPressed ifFalse: [ slider fillStyle: self normalThumbFillStyle; borderStyle: self normalThumbBorderStyle; changed ]. (self containsPoint: event position) ifTrue: [ upButton fillStyle: self mouseOverPagingAreaButtonFillStyle; borderStyle: self mouseOverPagingAreaButtonBorderStyle ] ifFalse: [ upButton fillStyle: self normalButtonFillStyle; borderStyle: self normalButtonBorderStyle ]. (self containsPoint: event position) ifTrue: [ downButton fillStyle: self mouseOverPagingAreaButtonFillStyle; borderStyle: self mouseOverPagingAreaButtonBorderStyle ] ifFalse: [ downButton fillStyle: self normalButtonFillStyle; borderStyle: self normalButtonBorderStyle ] Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 24, 2012

Re: [Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!

by Henrik Sperre Johansen

On 23.05.2012 20:18, Sven Van Caekenberghe wrote: > On 23 May 2012, at 19:48, Marcus Denker wrote: > >> No, the image as it is now just quits. Delayed our deployment of the ESUG registration server >> for some weeks... normal seaside use, image quites after a day. >> >> It's far from obvious. >> >> I think the image should work out of the box. Why destinguish between deployment and development? >> What is good in deployment is for sure gut in development. It's the other way around in this case, what's good in development is not always so good in deployment. In development, you want to be notified of issues as soon as possible. If they still slip through to deployment, you want them dealt with as gracefully as possible. > It might be a bit surprising, but I think Hendrik's reasoning is quite good: you don't want to keep on expanding when there are problems not freeing resources that are limited. A good server needs resource limits. > > We can discuss more tomorrowâ¦ > > Sven > > > Well, both that, and the fact it can't be done safely. The process of increasing its size might lead to lost signals. 99% of the time, setting the size at startup to a larger value than the default (before anything but the input semaphore is registered) is a better approach than increasing automatically, and in the remaining 1% it is better to fix whatever application issue is causing semaphore leaks anyways. Cheers, Henry

May 24, 2012

Re: [Pharo-project] Pharo Conference

by Craig Latta

Hi all-- Unfortunately I'm not able to attend either; other matters conspire to keep me in Amsterdam today. I do apologize. I hope you're all having a great time! I add my voice to the chorus eager for videos, and please do let me know if there's some way I can participate from here. cheers! Craig -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS)

May 24, 2012

Re: [Pharo-project] Pressed Morph feedback on PharoTheme

by Goubier Thierry

Le 23/05/2012 17:31, StÃ©phane Ducasse a Ã©crit : >> >> It makes the default interaction a lot more reactive (i.e. you notice > on screen when you are pressing on a button). > > Now with your change I do not understand why and when a button is > becoming blue. I think this is when the button has a true state, as used by the getStateSelector of the morph. This is visible in the Hierarchy/Flat button in Nautilus, where Hierarchy is state == false, and Flat is state == true (and has the blue color). In the case state true, PharoTheme may be falling back on the colors of the WateryTheme. Another bug shown with my change is, if you start to scroll with the slider, it depresses correctly, but, as soon as you move outside the bounds of the scrollbar, even while pressing the left mouse button, then the slider goes back to the "not pressed" state while you are still scrolling up or down. >> Side note about UI changes in Nautilus: will there be any changes > about the Groups/Hierarchy/Class/Comments buttons ? I have a hard time > getting used to them (lack of selection/state clues, unusual behavior > for buttons). > > Yes we all are saying that this is not working since we do not know if > the state we are in. Change with "toggle" buttons instead ? Playing with the Nautilus GUI, more interesting behavior(s) : * Select an empty package (_UnpackagedPackage) * Hierarchy button becomes disabled but * Instance / Class button is still enabled * Comment button is still enabled Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 24, 2012

Re: [Pharo-project] what is the magic with MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. ' ?

by Chris Muller

The downside is that it tethers you to the network if you happen to need access to the proxied ancestry. On Wed, May 23, 2012 at 4:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 23, 2012, at 7:09 PM, Chris Muller wrote: > >> I don't know if your goal is to save space but... Â one of the nice >> things I've been enjoying about using a Magma-based MC repository is >> that the VersionInfo chain only goes back as far as you've actually >> accessed. Â Beyond that it's terminated by a Proxy object. >> >> It's the best of both worlds: Â the full version history is instantly >> and transparently available but without taking up any space until it's >> accessed.. > > yes this is probably the way to go. > You mean until the analysis finds a merge? > > Stef > >> >> On Mon, May 21, 2012 at 2:42 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>> The immediate impact of this is that you wont' be able to use the packages in your image in a three way merge, because the system will no longer be able to find a common ancestor. By implication you shouldn't save any of the packages either, because you risk polluting the "package pool" with ancestor-less versions. >>> >>> I've done a little experimentation with this in the git work (at one point in time, I was not saving the ancestry information on disk) ... >>> >>> If you somehow record the immediate ancestor(s) of the package, you can restore the ancestry chain with the MonticelloBrowser 'adopt' operation and then you can do the merge or save the package ... >>> >>> You can save and load these puppies ... I'm pretty sure that the ancestry is used only for merging ... >>> >>> oh yeah, the name of the package with the author and version number is derived from the first ancestor, i.e., the package that was loaded into the image, while this doesn't cause explicit problems, it can be unsettling ... >>> >>> At least that's what I recall.... >>> >>> Dale >>> >>> ----- Original Message ----- >>> | From: "Mariano Martinez Peck" <marianopeck(a)gmail.com> >>> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> | Sent: Monday, May 21, 2012 10:58:23 AM >>> | Subject: [Pharo-project] what is the magic with MCVersionInfo allInstances do: [ :each | each instVarNamed: >>> | 'ancestors' put: nil ]. ' ? >>> | >>> | Hi guys. Can a MC guy tell me what happens when I do: >>> | >>> | MCVersionInfo allInstances do: [ :each | each instVarNamed: >>> | 'ancestors' put: nil ]. >>> | >>> | what is what is actually clean? is that useful? what are the >>> | consequences/impact when I do that? is my image broken? can I still >>> | use monticello browser and all my projects with it? >>> | >>> | thanks >>> | >>> | -- >>> | Mariano >>> | http://marianopeck.wordpress.com >>> | >>> | >>> >> >

May 24, 2012

Re: [Pharo-project] Progress bar in the top left

by Serge Stinckwich

On Wed, May 23, 2012 at 7:37 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > And probably bottom right is less annoying, since people is used to start > looking at the top right corner. Is it possible to have an uniform way to present announcement. There is already the growl-like announcements of tests used by the Nautilus Browser done ob botton left. Maybe progress bar should be done in the same screen area. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

May 24, 2012

Re: [Pharo-project] Posible bug

by Camillo Bruni

check the HOWTOBUILD file in the git repository + there is an image.sh script in the /image folder of the git repo I think the git repo should be the place to keep track of such documentation! On 2012-05-23, at 18:29, Sean P. DeNigris wrote: > > Igor Stasenko wrote >> >> because then it will be not from scratch. >> of course i using image(s) vmmaker built by jenkins, where all stuff >> already preloaded. >> but it important bit of knowledge, which people should know how things >> rolling. >> > > Okay, I got it. Would it be a good compromise to point them to the Jenkins > script that syncs the config with the current image? Is it LoadVMMaker.st? > Maybe this (or whatever information you would need to compile from scratch > that changes over time) could be added as an artifact to the Cog-VM on > Jenkins (or as another job, like "Build VM from Scratch"). This way, anyone > could go to the last successful build and see which versions of Pharo, > ConfigurationOfXxx, git, etc. were used and get the same result. > > -- > View this message in context: http://forum.world.st/Posible-bug-tp4631484p4631601.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 23, 2012