- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Update stream for released images

by Mariano Martinez Peck

On Thu, May 24, 2012 at 10:32 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Now that there will be bug fixes for released images, it seems like we > should > we keep "Software update" in the world menu, no? > > yes, it starts to make sense once again now :) > Sean > > -- > View this message in context: > http://forum.world.st/Update-stream-for-released-images-tp4631743.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

May 24, 2012

Re: [Pharo-project] Posible bug

by Sean P. DeNigris

Camillo Bruni-3 wrote > > 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! > I don't know enough about the process - will that guarantee a working build? Right now, Jenkins "Cog Git Tracker" is failing (not because of the sources this time). If there was something broken, using the versions of image/ConfigurationOfXxx, sources, etc. from Jenkins' last successful build would guarantee success anyway. Sean -- View this message in context: http://forum.world.st/Posible-bug-tp4631484p4631744.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

[Pharo-project] Update stream for released images

by Sean P. DeNigris

Now that there will be bug fixes for released images, it seems like we should we keep "Software update" in the world menu, no? Sean -- View this message in context: http://forum.world.st/Update-stream-for-released-images-tp4631743.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

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

by Sean P. DeNigris

StÃ©phane Ducasse wrote > > Now sometimes we should have a blocking UI. > As I've been working on NewSystemProgressMorph, I've been toying with whether the progress bar should be directly manipulated, as is the case now, or should just be another subscriber for progress announcements. This way it could be disabled by unsubscribing, and any other actions could be taken additionally/instead (e.g. send progress to stdout, transcript, etc.) -- View this message in context: http://forum.world.st/Progress-bar-in-the-top-left-tp4631530p4631730.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

Re: [Pharo-project] Suggestions about Nautilus Look

by Sean P. DeNigris

Fabrizio Perin-3 wrote > > I have a couple of propositions about the Nautilus look: > Great feedback! Thanks for taking the time to start the discussion... Fabrizio Perin-3 wrote > > 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. > The gray icons indicate that the package is clean. When there are unsaved changes, the color goes to red Fabrizio Perin-3 wrote > > 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? > Whatever color we make them, they will be less visible with *some* color background ;-) I *really* like that the visual color feedback is part of the testing domain. I know the test passed without moving my eyes to the corner to read the text. Your point about checking the background color and altering for some contrast is valid, but seems like a long-shot (how many people have those bold green/yellow colors as backgrounds?!). I would guess if you're passionate about it, you should implement it yourself and submit the code :) Sean -- View this message in context: http://forum.world.st/Suggestions-about-Nautilus-Look-tp4631723p4631728.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012

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

by StÃ©phane Ducasse

Indeed. > 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. Now sometimes we should have a blocking UI. Stef > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >

May 24, 2012

[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