- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] left over when resizing window

by Esteban Lorenzano

On 03 Apr 2014, at 17:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 3 April 2014 16:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > that happens in retina displays. > Iâm awareâ¦ no time yet to fix it :( > > Esteban, still on holidays > > btw, again and again i forgetting ask you to show me what i should change to disable "half resolution" mode > while on retina displays.. > i wanna use full resolution, for aestetical testing of font rendering without subpixel(s).. > by athens/cairo :) basically, we have to change the scale of the NSView who contains the world. probably trivialâ¦ but one of those small things I never found the time to fix (always something more urgent). Esteban (yepâ¦ still on holidays :P) > > > > On 03 Apr 2014, at 11:32, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > > This is this kind of glitches (see screenshot) ? > > I already talk about that some months ago in the mailing-list. > > > > On Thu, Apr 3, 2014 at 3:11 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Funny that you do not see the same issues. > >> > >> I reproduce it consistently like this: > >> - On 10.9.2 on a MacBook Pro with Retina display > >> - Download the latest Pharo 3 and the latest VM and run it: > >> curl -L get.pharo.org/30+vmLatest | sh > >> - Open a workspace or any other window and drag it around > >> > >> > >> Doru > >> > >> > >> Doru > >> > >> > >> On Thu, Apr 3, 2014 at 3:04 PM, Camille Teruel <camille.teruel(a)gmail.com> > >> wrote: > >>> > >>> > >>> On 3 avr. 2014, at 14:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>> > >>> Hi, > >>> > >>> Here it is on the very latest of Pharo 3: > >>> > >>> https://www.dropbox.com/s/hfi5j64e9kyim14/Screenshot%202014-04-03%2014.56.3… > >>> > >>> > >>> Ok, now I remember that I had that once several months ago, but I don't > >>> remember under which setting. > >>> I solved it with 'start drawing/stepping again' as Sergi said. > >>> We should find a way to reproduce it. > >>> > >>> > >>> Pharo3.0 Latest update: #30811 > >>> 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > >>> acc98e51-2fba-4841-a965-2975997bba66 Mar 20 2014 > >>> NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: > >>> acc98e51-2fba-4841-a965-2975997bba66 Mar 20 2014 > >>> https://github.com/pharo-project/pharo-vm.git Commit: > >>> 6e08ad296c0df6c1a4215a5dada5380c897dc2fe Date: 2014-03-17 14:45:12 +0100 By: > >>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14812' > >>> > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> > >>> > >>> On Thu, Apr 3, 2014 at 2:33 PM, Camille Teruel <camille.teruel(a)gmail.com> > >>> wrote: > >>>> > >>>> > >>>> On 3 avr. 2014, at 14:21, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>>> > >>>> It happens all the time on Mac. It is not so obvious in the default Pharo > >>>> image because of the background. In the Moose image, the background is white > >>>> and you see it immediately when resizing or dragging a window. > >>>> > >>>> > >>>> I tried with many windows in the latest Moose image and I still see > >>>> nothing. > >>>> I'm on mavericks. > >>>> > >>>> Smalltalk vm version --> > >>>> > >>>> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > >>>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > >>>> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > >>>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > >>>> git://gitorious.org/cogvm/blessed.git Commit: > >>>> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: > >>>> Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > >>>> ' > >>>> > >>>> > >>>> Doru > >>>> > >>>> > >>>> On Thu, Apr 3, 2014 at 2:16 PM, Camille Teruel <camille.teruel(a)gmail.com> > >>>> wrote: > >>>>> > >>>>> > >>>>> On 3 avr. 2014, at 13:54, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > >>>>> > >>>>>> Hi all > >>>>>> > >>>>>> do you see a glitch when I resize a window? > >>>>>> Because it is not really nice. > >>>>> > >>>>> Nope, nothing in latest image at least. > >>>>> Does it happen in a fresh image? > >>>>> > >>>>>> Stef > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Every thing has its own flow" > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >>> > >>> > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > > > > > > > > -- > > Serge Stinckwich > > UCBN & UMI UMMISCO 209 (IRD/UPMC) > > Every DSL ends up being Smalltalk > > http://www.doesnotunderstand.org/ > > <Screen Shot 2014-04-03 at 16.30.05.png> > > > > > > -- > Best regards, > Igor Stasenko.

April 4, 2014

font folder on win7

by Pharo4Stef

Hi guys Iâm trying to understand why people get problems with fonts on windows. The logic in the font manager is 'cdefghijklmnopqrstuvwxyz' et pour chaque disc dans '\windows\fonts' '\winnt\fonts but I wonder if the location of font on windows 7 is correct. Can anybody with a window 7 report where the fonts are located? stef

April 4, 2014

Re: [Pharo-dev] Suggested Syntax Highlighting Features for Beginners

by Ben Coman

J.F. Rick wrote: > Smalltalk is a pretty great language, but its syntax is unusual. I've > taught introductory programming in Pharo three times and, in my > experience, there are two places where novices get repeatedly confused > with syntax. > > First, there is the differences between assignment := and comparison = > . Obviously, Smalltalk is not the only language where that is a > problem. Java is even more confusing, with assignment = and comparison > == . In Squeak, there was the attempt to address this problem head on > with using _ instead of := and having it show up as an arrow pointing > left; while that nicely addressed that problem, it proved awkward for > many reasons (e.g., it only appeared as an arrow in Squeak, it wasn't > compatible with other Smalltalks). In addition, comparison is a simple > message send, where assignment is the most critical language element > that is not an object or a message. In other words, there is a huge > difference in meaning between the two and a really minor syntactical > one. That's confusing to novices. Even after covering it repeatedly in > class I still find novices making that mistake. As their debugging > skills are minimal, this can be a real obstacle. > > Second, there is the problem of keyword messages with more than one > argument. In Java, "this.someMessage( arg1, arg2)" is pretty > comprehensible to a novice. In Smalltalk, "self someMessage: arg1 and: > arg2" seems like two message sends (i.e., > "this.someMessage(arg1).and(arg2)"). While novices won't see > multi-argument messages very often, they do come up (e.g., > ifTrue:ifFalse:). I have my class do regular quizzes on identifying > messages and this still tricks them up even if they've already seen in > 10 times. > > Now, I'm not advocating changing the Smalltalk syntax; that's just > unlikely to happen. But, perhaps syntax highlighting could be employed > to good use. For instance, it is extremely helpful that blocks and > parentheses show by color which ( [ go with which ] ). Perhaps > something similar could be done for messages with more than 1 > argument. For instance, the message could be underlined in different > colors. That way I could easily see which ifFalse: went with which > ifTrue:. It would also give a visual indicator: (for novices) Be > careful, this message is one of those weird ones that's longer than it > first appears. For assignment vs comparison, you similarly need a > powerful visual cue that assignment is an usual thing, where > comparison is a pretty ordinary thing. Perhaps an arrow decoration > could appear behind the :=. > > These may seem like trivial issues. For experts, they are. I don't > need any of it. I don't find syntax highlighting and command > completion that useful in my programming. But, I'm proficient with a > debugger. Should I occasionally make such a trivial mistake (e.g., > forgetting to type : in :=), I immediately find it while debugging and > easily fix it. For novices, using a debugger is not an option. > Remember, they don't understand what a stack is. Syntax highlighting > is the best debugging feature that they understand. And these are two > real common mistakes that they make that could be addressed by > improvements to syntax highlighting. > > Just a suggestion, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick For assignment, I would say bold both := and the variable being assigned to. Underlining sounds interesting, but there are a few choices: a. nested underlining - self someMessage: (self otherMessage: arg 1 and: arg2) and: arg3 b. non-nested underlining - only underline #otherMessage:and: and not #someMessage:and: c. dynamically underline only message where cursor is located. I prefer (c.). This would be least annoying to the experts, and maybe not even need a Preference. Students don't have it as a continual crutch - but they can easily check whenever needed with a tight feedback loop most productive for learning. cheers, Ben

April 4, 2014

Re: [Pharo-dev] Lock-free Atomic Counter ?

by Sven Van Caekenberghe

Just for the sake of discussion, you try to prevent interruptions by using assignments, right ? But you still need #== which seems like a (potential) message send, which brings us back to the other arguments in this thread. Furthermore, the dummy value must be different for each of the processes/threads entering, no ? On 03 Apr 2014, at 01:34, Igor Stasenko <siguctua(a)gmail.com> wrote: > so, lock-free counter can be something like: > > atomicIncr > | oldValue | > > [ > oldValue := self atomicSwapCounterWithDummy. > oldValue == dummy ] whileTrue: [ Processor yield ]. > > ^ counter := oldValue + 1 > > > atomicSwapCounterWithDummy > | old | > old := counter. > counter := dummy. > ^ old > > so you use dummy to block anyone from setting the new value unless you set it. > dummy can be any object (not a number in your care), > and lastly, once you assign a new value, you effectively release a "lock" > :) > > Processor yield is mainly attempt to avoid busy-waiting. > > > > On 3 April 2014 01:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 3 April 2014 00:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Is it possible to have a simple lock-free atomic counter in Pharo 3.0 ? > > nextId > ^ idCounter := idCounter + 1 > > Or is it still possible that two process entering this code can mess things up ? > > #+ is a message send. So technically, if you will be interrupted at the point of > returning a result from it, then somebody else could run #nextId without notice, > as result you will get 2 processes returning same value from #nextId. > (and increasing numbers of concurrent processes will produce even more surprising results :) > > I vaguely remember a discussion about that long ago... > > assignment is atomic.. the one which i use in atomic queue impl., but it is hidden, undocumented VM implementation detail :) e.g.: > > oldA := a. > a := newA. > .. > actually can be any series of it, as long as nothing else there (no message sends) > > x:= a. > y:=b. > z := c. > w := e. > > will be performed atomically. > > > TIA, > > Sven > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko.

April 4, 2014

Re: [Pharo-dev] Lock-free Atomic Counter ?

by Sven Van Caekenberghe

Thanks guys for all the answers, I think I am going to stick with the simple code and no protection based on the arguments that I read. It will do for my application where nothing catastrophic will happen when in case of a clash. On 03 Apr 2014, at 00:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Is it possible to have a simple lock-free atomic counter in Pharo 3.0 ? > > nextId > ^ idCounter := idCounter + 1 > > Or is it still possible that two process entering this code can mess things up ? > > I vaguely remember a discussion about that long ago... > > TIA, > > Sven

April 4, 2014

Re: [Pharo-dev] [pharo3 issues] down to 17 issues

by MartinW

When i add a new bug to the issue tracker it is automatically tagged as "fix if time". Am i supposed to change this label to higher priority if i think it's appropriate - or is someone reviewing new entered bugs and assigning priorities to them? Anyway here's the bug: https://pharo.fogbugz.com/f/cases/13175/ -- View this message in context: http://forum.world.st/pharo3-issues-down-to-17-issues-tp4752772p4752800.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 4, 2014

Suggested Syntax Highlighting Features for Beginners

by J.F. Rick

Smalltalk is a pretty great language, but its syntax is unusual. I've taught introductory programming in Pharo three times and, in my experience, there are two places where novices get repeatedly confused with syntax. First, there is the differences between assignment := and comparison = . Obviously, Smalltalk is not the only language where that is a problem. Java is even more confusing, with assignment = and comparison == . In Squeak, there was the attempt to address this problem head on with using _ instead of := and having it show up as an arrow pointing left; while that nicely addressed that problem, it proved awkward for many reasons (e.g., it only appeared as an arrow in Squeak, it wasn't compatible with other Smalltalks). In addition, comparison is a simple message send, where assignment is the most critical language element that is not an object or a message. In other words, there is a huge difference in meaning between the two and a really minor syntactical one. That's confusing to novices. Even after covering it repeatedly in class I still find novices making that mistake. As their debugging skills are minimal, this can be a real obstacle. Second, there is the problem of keyword messages with more than one argument. In Java, "this.someMessage( arg1, arg2)" is pretty comprehensible to a novice. In Smalltalk, "self someMessage: arg1 and: arg2" seems like two message sends (i.e., "this.someMessage(arg1).and(arg2)"). While novices won't see multi-argument messages very often, they do come up (e.g., ifTrue:ifFalse:). I have my class do regular quizzes on identifying messages and this still tricks them up even if they've already seen in 10 times. Now, I'm not advocating changing the Smalltalk syntax; that's just unlikely to happen. But, perhaps syntax highlighting could be employed to good use. For instance, it is extremely helpful that blocks and parentheses show by color which ( [ go with which ] ). Perhaps something similar could be done for messages with more than 1 argument. For instance, the message could be underlined in different colors. That way I could easily see which ifFalse: went with which ifTrue:. It would also give a visual indicator: (for novices) Be careful, this message is one of those weird ones that's longer than it first appears. For assignment vs comparison, you similarly need a powerful visual cue that assignment is an usual thing, where comparison is a pretty ordinary thing. Perhaps an arrow decoration could appear behind the :=. These may seem like trivial issues. For experts, they are. I don't need any of it. I don't find syntax highlighting and command completion that useful in my programming. But, I'm proficient with a debugger. Should I occasionally make such a trivial mistake (e.g., forgetting to type : in :=), I immediately find it while debugging and easily fix it. For novices, using a debugger is not an option. Remember, they don't understand what a stack is. Syntax highlighting is the best debugging feature that they understand. And these are two real common mistakes that they make that could be addressed by improvements to syntax highlighting. Just a suggestion, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

April 4, 2014

Milestone for 11908 Need-to-show-warning-when-no-changes-file-found

by Ben Coman

April 4, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30814 Home: https://github.com/pharo-project/pharo-core

April 4, 2014

[pharo-project/pharo-core] c70984: 30814

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: c709840678b461310cb9742ec575c6bf73aa85bd https://github.com/pharo-project/pharo-core/commit/c709840678b461310cb9742e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-04 (Fri, 04 Apr 2014) Changed paths: M Athens-Cairo.package/CairoFontFace.class/class/instance creation/fromFreetypeFace_.st M Athens-Cairo.package/CairoFontMetricsProvider.class/instance/accessing/fontHeight.st M Athens-Cairo.package/CairoFontMetricsProvider.class/instance/accessing/font_.st R Athens-Cairo.package/CairoFontRenderer.class/README.md R Athens-Cairo.package/CairoFontRenderer.class/definition.st R Athens-Cairo.package/CairoFontRenderer.class/instance/acccessing/fontMetricsProviderFor_.st M Athens-Cairo.package/CairoFreetypeFontRenderer.class/README.md A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing - font metrics/fontAscent.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing - font metrics/fontHeight.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing - font metrics/getGlyphWidth_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing - font metrics/glyphsOf_from_to_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing/advance.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing/advance_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing/canvas_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing/font_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/accessing/setColor_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/advance.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/advance_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/canvas_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/convertString_len_ofFont_toGlyphs_numGlyphs_x_y_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/fontAscent.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/fontHeight.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/font_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/freeGlyphs_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/getGlyphWidth_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/glyphsOf_from_to_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/initialize.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/renderCharacters_from_to_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/render_.st R Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/as yet unclassified/setColor_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/initialize/initialize.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/private/convertString_len_ofFont_toGlyphs_numGlyphs_x_y_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/private/freeGlyphs_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/rendering/renderCharacters_from_to_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/rendering/renderGlyphs_.st A Athens-Cairo.package/CairoFreetypeFontRenderer.class/instance/rendering/render_.st A Athens-Cairo.package/CairoScaledFont.class/class/instance creation/fromFreetypeFont_.st M Athens-Cairo.package/CairoScaledFont.class/class/instance creation/fromFreetypeFont_cairoFace_.st R Athens-Cairo.package/CairoScaledFont.class/instance/as yet unclassified/set%5FCTM_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script467.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30814.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Core.package/ComposableModel.class/instance/accessing/defaultWindowModelClass.st M Spec-Core.package/ComposableModel.class/instance/protocol/openWithSpecLayout_.st M Spec-Core.package/DynamicComposableModel.class/instance/instance creation/instantiateModels_.st M Spec-Core.package/SpecAdapterBindings.class/instance/initialize/initializeBindings.st A Spec-Core.package/TickingSpecWindow.class/README.md A Spec-Core.package/TickingSpecWindow.class/definition.st A Spec-Core.package/TickingSpecWindow.class/instance/stepping and presenter/step.st A Spec-Core.package/TickingSpecWindow.class/instance/stepping/stepTime.st A Spec-Core.package/TickingSpecWindow.class/instance/stepping/wantsSteps.st A Spec-Core.package/TickingWindowModel.class/README.md A Spec-Core.package/TickingWindowModel.class/class/specs/adapterName.st A Spec-Core.package/TickingWindowModel.class/class/specs/defaultSpec.st A Spec-Core.package/TickingWindowModel.class/definition.st A Spec-Core.package/TickingWindowModel.class/instance/initialization/step.st A Spec-Core.package/TickingWindowModel.class/instance/stepping/stepTime.st M Spec-Debugger.package/SpecDebugger.class/instance/initialization/initializePresenter.st R Spec-Debugger.package/SpecDebugger.class/instance/initialization/resetAutoRefresh.st M Spec-Debugger.package/SpecDebuggerStack.class/instance/printing/columnsFor_.st M Spec-Debugger.package/SpecPreDebugWindow.class/instance/actions/openFullDebugger.st R Spec-Inspector.package/EyeAbstractInspector.class/instance/accessing/updateTime.st M Spec-Inspector.package/EyeCollectionInspector.class/instance/accessing/title.st R Spec-Inspector.package/EyeInspector.class/class/accessing/useAutoRefresh.st R Spec-Inspector.package/EyeInspector.class/class/accessing/useAutoRefresh_.st R Spec-Inspector.package/EyeInspector.class/class/settings/defaultBrowserSettingOn_.st M Spec-Inspector.package/EyeInspector.class/definition.st R Spec-Inspector.package/EyeInspector.class/instance/event-handling/ownerChanged.st R Spec-Inspector.package/EyeInspector.class/instance/initialization/initializeAutoRefresh.st R Spec-Inspector.package/EyeInspector.class/instance/initialization/resetAutoRefresh.st A Spec-Inspector.package/EyeInspector.class/instance/initialization/step.st M Spec-Inspector.package/EyeInspector.class/instance/menu/inspectionMenu_.st R Spec-Inspector.package/EyeInspector.class/instance/testing/useAutoRefresh.st M Spec-Inspector.package/EyeMorphViewer.class/definition.st R Spec-Inspector.package/EyeMorphViewer.class/instance/event-handling/close.st R Spec-Inspector.package/EyeMorphViewer.class/instance/initialize/initialize.st A Spec-Inspector.package/EyeMorphViewer.class/instance/initialize/step.st A Spec-Inspector.package/InspectorNavigator.class/instance/accessing/defaultWindowModelClass.st A Spec-Inspector.package/InspectorNavigator.class/instance/initialization/step.st A Spec-Inspector.package/InspectorNavigator.class/instance/initialization/stepTime.st M Spec-MorphicAdapters.package/MorphicAdapterBindings.class/instance/initialize/initializeBindings.st M Spec-MorphicAdapters.package/MorphicContainerAdapter.class/instance/protocol/isRedrawable.st A Spec-MorphicAdapters.package/MorphicTickingWindowAdapter.class/README.md A Spec-MorphicAdapters.package/MorphicTickingWindowAdapter.class/class/specs/defaultSpec.st A Spec-MorphicAdapters.package/MorphicTickingWindowAdapter.class/definition.st A Spec-MorphicAdapters.package/MorphicTickingWindowAdapter.class/instance/stepping/step.st Log Message: ----------- 30814 12777 Athens font cacheing bug https://pharo.fogbugz.com/f/cases/12777 12460 eyeinspector refresh loop https://pharo.fogbugz.com/f/cases/12460 http://files.pharo.org/image/30/30814.zip

April 4, 2014