- Pharo-dev - lists.pharo.org

Re: [Pharo-project] VM problem?

by Benjamin

It happened to me a couple of time when editing methods in the senders/implementors. I never found out why Ben On May 25, 2012, at 10:12 AM, Tudor Girba wrote: > The problem is also reproducible with the latest Nautilus 1.4 image. > > Doru > > > On 25 May 2012, at 09:57, Fabrizio Perin wrote: > >> Hi, >> I'm using last Moose build on top of CogVM 2550 and each time I click on a method an error pops up (see the attachment). The same problem I have it with older builds of Moose but I don't have any problem if I open the same image with Cog VM 2540 or CogVM from the Pharo web site. >> >> I'm on Mac os 10.7.4 and the image is: >> >> Pharo1.4 >> Latest update: #14438 >> >> Cheers, >> Fabrizio >> >> <MooseAnd2550Error.tiff> > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > >

May 25, 2012

[Pharo-project] iOS VM III - new error...

by phil＠highoctane.be

Ok, got the latest blessed/ from git this morning. Saw that there was a new .image and .changes After having downloaded (Xcode didn't asked but went on...) the 10.7 libs update, I compiled and ran the VM on the iPad2. New error in the output log in Xcode: 2012-05-25 10:09:28.807 iStackVM[4364:707] Application windows are expected to have a root view controller at the end of application launch errno 12 startOfmmapForANONMemory failed: Cannot allocate memory Mmmmh, this stinks. Anyone having this as well? I'll be at the Pharoconf this afternoon, maybe someone can help me fix this one. KR -- Philippe Back "Helping you hit the top 3 outcomes you really want to achieve" Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges

May 25, 2012

Re: [Pharo-project] VM problem?

by Tudor Girba

The problem is also reproducible with the latest Nautilus 1.4 image. Doru On 25 May 2012, at 09:57, Fabrizio Perin wrote: > Hi, > I'm using last Moose build on top of CogVM 2550 and each time I click on a method an error pops up (see the attachment). The same problem I have it with older builds of Moose but I don't have any problem if I open the same image with Cog VM 2540 or CogVM from the Pharo web site. > > I'm on Mac os 10.7.4 and the image is: > > Pharo1.4 > Latest update: #14438 > > Cheers, > Fabrizio > > <MooseAnd2550Error.tiff> -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

May 25, 2012

[Pharo-project] VM problem?

by Fabrizio Perin

Hi, I'm using last Moose build on top of CogVM 2550 and each time I click on a method an error pops up (see the attachment). The same problem I have it with older builds of Moose but I don't have any problem if I open the same image with Cog VM 2540 or CogVM from the Pharo web site. I'm on Mac os 10.7.4 and the image is: Pharo1.4 Latest update: #14438 Cheers, Fabrizio

May 25, 2012

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

by Igor Stasenko

On 24 May 2012 17:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. > Since when? Rule #1 of UI: never block UI. Because if you do, then we have no right to call it UI. do you know why we need this panic button (Alt-.) in our images? Exactly because every silly thing prefers to block UI at any point, even if it doesn't necessary. -- Best regards, Igor Stasenko.

May 25, 2012

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

by Igor Stasenko

On 23 May 2012 14:33, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Mariano Martinez Peck wrote >> >> I think it is much better since Â it does not disturb you. >> > > Fine by me, but the progress bar usually blocks the UI anyway, only updating > itself. Do we want it to drive the world instead? That way we can keep > working on other things, but I'm guessing e.g. MC loading will be much > slower... progress bar doesn't blocks anything, it is a code which using it blocks everything. You can try an experiment - remove progress bar, and still will be blocked, but this time without a clue what's going on :) Unless loading is atomic, i would not recommend allow keep working. However, i don't see a compelling reason why MC cannot load stuff in background : User can do silly things.. but it can be any other process with higher priority.. and you cannot predict what that process will do anyways. I remember i was saying this before: it is better to fix MC, if we find issues due to change. Like that it will be more fail proof plus we will no longer need to block user. Needless to say that i hate this mode when everything is disabled. > > -- > View this message in context: http://forum.world.st/Progress-bar-in-the-top-left-tp4631530p4631549.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

May 25, 2012

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

by Sean P. DeNigris

Sean P. DeNigris wrote > > As I've been working on NewSystemProgressMorph > NewSystemProgressMorph feels ready... The most significant change is that now, when you use methods like String>>displayProgressFrom:to:during:, you have a real API for updating the progress bar. Instead of sending symbols to a block*, you send messages to aSystemProgressItemMorph. For example: bar value: 'newLabel' -> bar label: bar value: #increment -> increment * see SystemProgressMorph>>label:min:max: for the mess we had before Issue 5969: [ENH]: Clean SystemProgressMorph and friends (Part 2) http://code.google.com/p/pharo/issues/detail?id=5969 This version is much cleaner and seems to work well. I tested it loading a few Metacello configurations. There is a small issue where long labels make the morph off-center for an instant, but it seems like we're moving toward putting it in a corner anyway (http://forum.world.st/Progress-bar-in-the-top-left-td4631530.html) so I won't spend time fixing it now... Fix in inbox: SLICE-Issue-5969-ENH-Clean-SystemProgressMorph-and-friends-Part-2-SeanDeNigris.1 * Cleanup new classes - categorize all uncategorized methods - a lot of little cleanups, refactors - NewSystemProgressMorph - remove forking - fix recentering when long labels are added * Integrate new classes with the system - Replace SystemProgressMorph with NewSystemProgressMorph (i.e. remove SystemProgressMorph and rename NewSystemProgressMorph to SystemProgressMorph) - SystemProgressBarMorph -> ProgressBarMorph (there is nothing "system"-specific about it. It is generally useful - ProgressInitiationException>>defaultMorphicAction - update to new classes/functionality * related changes - Collection>>do:displayingProgress:every: - return immediately for empty collections - if aStringOrBlock is aString, use it right away - Polymorph - fixed some formatting (e.g. double spaces) Status: FixReviewNeeded -- View this message in context: http://forum.world.st/Progress-bar-in-the-top-left-tp4631530p4631763.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 Esteban Lorenzano

On 24/05/2012, at 18:06, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > > 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.) +1 > > -- > 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 Fabrizio Perin

Hi, > 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 > I have noticed that but what I'm saying is that we know those are packages because that is a package browser. The gray icons are a redundant information and so not useful and also visually disturbing. I think, if you don't have to tell me something in particular like that there are unsaved changes, there should be no icon on the packages. > > 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 :) > > I also like that notification. What I'm saying here is that the color of the text into the feedback is white (or transparent and so white since I have white background) and so it is not really readable in case the feedback is green or yellow accordingly to the tests result. But this is a really tiny point. Regards, Fabrizio

May 24, 2012

[Pharo-project] Bug fixes for 1.4

by Sean P. DeNigris

There is a bug in 1.4 where a trailing slash causes FileReference>>exists to return false e.g. on my machine, "(FileLocator home asFileReference / '.jenkins/') exists" -> false "(FileLocator home asFileReference / '.jenkins') exists" -> true I noticed it has been fixed in 2.0 and tracked the change down to DiskStore>>nodeAt:ifPresent:ifAbsent:. Now how do I figure out where this change came from? I didn't see anything promising in the issue tracker. Assuming this was part of a slice, I want to make sure I include any associated changes to other packages. Also, this makes me wonder again about the tagging process. It seems this should have gone into both 1.4 and 2.0 if I correctly understand the new release process... Sean -- View this message in context: http://forum.world.st/Bug-fixes-for-1-4-tp4631751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2012