April 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Don't do this X(

by phil＠highoctane.be

On Wed, Apr 2, 2014 at 4:06 PM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > > > Le 02/04/2014 15:59, Sebastian Sastre a Ã©crit : > >> Advice: >> >> Never save a "big" package using monticello (lets say ~2000 classes) >> >> and then save the image >> >> Why? >> >> Because while you don't have feedback of saving progress* it will be >> doing something on background (forked save?) and if for any reason you >> are tempted to do an image save or save and quit, it will save in a >> state that will prevent the image from opening again >> >> You have no option but to go to your previous image version or something >> of the kind >> >> :( >> >> *saving a package actually provides /some/ feedback on progress but when >> the progress bar finishes, the saving doesn't actually finish and it >> still have something going on, so you get "silence" (no-feedback) until >> you get the little monticello window with your new package version >> > > Does this mean that once we get the little window, we are safe? I am saving a package with containing a lot of Pack-XXX Pack-YYY Pack-ZZZ in a 2.0 image as a single Pack-PhilippeBack-nn.mcz thing. What is the moves to make to be safe? I already got my image locked at some points in a way that resembles what you describe. Phil > I'll profile that to see what's happening. > > 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 > >

April 2, 2014

Re: [Pharo-dev] Don't do this X(

by Goubier Thierry

Le 02/04/2014 15:59, Sebastian Sastre a Ã©crit : > Advice: > > Never save a âbig" package using monticello (lets say ~2000 classes) > > and then save the image > > Why? > > Because while you donât have feedback of saving progress* it will be > doing something on background (forked save?) and if for any reason you > are tempted to do an image save or save and quit, it will save in a > state that will prevent the image from opening again > > You have no option but to go to your previous image version or something > of the kind > > :( > > *saving a package actually provides /some/ feedback on progress but when > the progress bar finishes, the saving doesnât actually finish and it > still have something going on, so you get "silenceâ (no-feedback) until > you get the little monticello window with your new package version I'll profile that to see what's happening. 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

April 2, 2014

Don't do this X(

by Sebastian Sastre

Advice: Never save a âbig" package using monticello (lets say ~2000 classes) and then save the image Why? Because while you donât have feedback of saving progress* it will be doing something on background (forked save?) and if for any reason you are tempted to do an image save or save and quit, it will save in a state that will prevent the image from opening again You have no option but to go to your previous image version or something of the kind :( *saving a package actually provides some feedback on progress but when the progress bar finishes, the saving doesnât actually finish and it still have something going on, so you get "silenceâ (no-feedback) until you get the little monticello window with your new package version

April 2, 2014

Re: [Pharo-dev] <quote author="Sean P. DeNigris"> I think the tree nodes should be based on name-matching and not only per-package. For example: </quote> In 4.0, let's query the Metacello configurations to find out exactly what packages belong to which project and categorize from there, but until then, I think this is already an improvement:

by Goubier Thierry

Hi Sean, I got a simple version of your configuration querying idea working. Regards, Thierry Le 24/01/2014 03:11, Sean DeNigris a Ã©crit : > > I think the tree nodes should be based on name-matching and not only > per-package > I should've appended: "as a compromise for the time being"... > > In 4.0, imagine this killer combination: > - Declare high-level logical categories a la AltBrowser (e.g. UI). This > really nails the 7+/-2 sweet spot > - For external projects, query the Metacello configurations to find out > exactly what packages belong to which project and group accordingly; -- 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

April 2, 2014

[pharo-project/pharo-core]

by GitHub

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

April 2, 2014

[pharo-project/pharo-core] 447842: 30808

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 44784270687434389f23c29d6736081af817df28 https://github.com/pharo-project/pharo-core/commit/44784270687434389f23c29d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-02 (Wed, 02 Apr 2014) Changed paths: A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script461.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30808.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Inspector.package/AbstractEyeElement.class/instance/comparing/=.st A Spec-Inspector.package/AbstractEyeElement.class/instance/comparing/hash.st A Spec-Inspector.package/BasicIndexedEyeElement.class/instance/comparing/=.st A Spec-Inspector.package/BasicIndexedEyeElement.class/instance/comparing/hash.st M Spec-Inspector.package/EyeInspector.class/instance/event-handling/refresh.st M Spec-Inspector.package/EyeInspector.class/instance/event-handling/updateList.st A Spec-Inspector.package/InstanceVariableEyeElement.class/instance/comparing/=.st A Spec-Inspector.package/InstanceVariableEyeElement.class/instance/comparing/hash.st M Spec-MorphicAdapters.package/MorphicTabManagerAdapter.class/instance/spec protocol/addTab_.st A Spec-MorphicAdapters.package/extension/LayoutFrame/instance/isHorizontallyResizeable.st A Spec-MorphicAdapters.package/extension/LayoutFrame/instance/isVerticallyResizeable.st A Spec-MorphicAdapters.package/extension/PanelMorph/instance/checkMorphsLeftOrTopFrom_.st A Spec-MorphicAdapters.package/extension/PanelMorph/instance/checkMorphsLeftOrTopFrom_size_.st A Spec-MorphicAdapters.package/extension/PanelMorph/instance/checkMorphsRightOrBottomFrom_.st M Spec-MorphicAdapters.package/extension/PanelMorph/instance/checkSplitters.st A Spec-MorphicAdapters.package/extension/PanelMorph/instance/isResizeableMorph_forSplitter_.st Log Message: ----------- 30808 13156 EyeInspector does not automatically refresh its list https://pharo.fogbugz.com/f/cases/13156 13163 Splitters move more morphs that needed https://pharo.fogbugz.com/f/cases/13163 http://files.pharo.org/image/30/30808.zip

April 2, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by J.F. Rick

Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem. Cheers, Jeff On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > okay i uploaded updated configs for NativeBoost and Athens into official > repositories for these projects. > > Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost'; > configuration; > load. > > ConfigurationOfNativeBoost loadDevelopment. > > > > Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; > configuration; > load. > > ConfigurationOfAthens loadDevelopment. > > > shall do the trick.. > > for more details see > > https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-diffe… > > > > On 28 March 2014 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > >> thanks Igor. >> I'm trying to look at the font reloading bug. >> >> >> On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-diffe… >> >> >> On 28 March 2014 16:42, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> so, the quick and dirty fix is to put: >>> >>> CairoGlyph class>>byteAlignment >>> >>> NativeBoost platformId = NativeBoostConstants win32PlatformId >>> ifTrue: [ ^ 8 ]. >>> ^ super byteAlignment >>> >>> and then: >>> >>> CairoGlyph rebuildFieldAccessors >>> CairoGlyphsArray initialize >>> >>> (note you must run this snippet each time your image changes platform).. >>> >>> and i need more time to fix it for real, because it is NB issue, to >>> automatically recalculate the structs size >>> if it changes platform.. (which also means you cannot store instances of >>> struct in image which survive the session) >>> ... damn.. that's going to be complicated. >>> >>> --- >>> >>> >>> >>> On 28 March 2014 16:27, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> >>>> >>>> >>>> On 28 March 2014 16:01, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> >>>>> Ookkayy.. >>>>> so, current status: >>>>> >>>>> - finally we got an agreement that big red square because of font >>>>> loading issues and font rendering artifacts is two separate issues. >>>>> Thanks! >>>>> - i am not going to address font-loading issue here and now.. (because >>>>> we spent time on it earlier today with Stef already and you should have the >>>>> report on it in separate mail). >>>>> >>>>> - we seem to be agreed that it is best to use same (up-to-date >>>>> version) of software when reporting issues to work on them. Thanks again. :) >>>>> >>>>> - while on linux and mac things seem to be working fine, i can confirm >>>>> that there is rendering artifacts (same as reported by Vincent) on Windows. >>>>> >>>>> so i going to explore what causing this problem.. >>>>> >>>>> ... and found the cause: >>>> >>>> On windows, for unknown reason, the structure (cairo_glyph_t) uses >>>> different memory space alignment than on mac and linux >>>> >>>> fieldsDesc >>>> ^ #( >>>> ulong index; >>>> double x; >>>> double y; >>>> ) >>>> >>>> on mac and linux , the size of this structure in memory = 4 + 8 + 8 = >>>> 20 bytes, >>>> on windows, however, due to 8-byte alignment, it is 4 + 8 + 8 + (4 >>>> alignment) bytes... >>>> >>>> this causing the effect that if you copy array of glyphs in memory, >>>> it does not copying whole array by slightly less (because it uses >>>> wrong struct size which is smaller than it is).. >>>> and because of that, you got weird artefacts at the tail of string, >>>> replaced by misplaced/invalid characters etc.. >>>> because it is basically read from uninitialized part of memory with >>>> random data. >>>> >>>> i going to fix structure alignment for windows from default 4 bytes to >>>> 8 bytes.. >>>> but this is not very good news.. because this affecting many things... >>>> (as you can imagine, not only cairo/athens working with external >>>> structures, which need to be properly aligned). >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

April 2, 2014

Re: [Pharo-dev] Bug in ZnUTF8Encoder

by Sven Van Caekenberghe

Hi Igor, Great catch ! How did you stumble upon this one ? Anyway, it shows that unless you really test all boundaries explicitly, silly one-off errors like that manage to survive for quite some time. I added a unit test doing just that. Fixed upstream: === Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.31 Author: SvenVanCaekenberghe Time: 2 April 2014, 2:14:36.890651 pm UUID: 3f6ae285-2973-4451-833b-16afbd0658d3 Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.30 Fixed a one-off error in ZnUTF8Encoder>>#nextPut:toStream (thanks Igor Stasenko) === Name: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.18 Author: SvenVanCaekenberghe Time: 2 April 2014, 2:15:51.938152 pm UUID: c7048056-52ae-484f-a466-7d537f66690a Ancestors: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.17 Fixed a one-off error in ZnUTF8Encoder>>#nextPut:toStream (thanks Igor Stasenko) Added ZnCharacterEncoderTests>>#testUTF8Boundaries === Thanks again, Sven On 02 Apr 2014, at 13:18, Igor Stasenko <siguctua(a)gmail.com> wrote: > nextPut: character toStream: stream > ... > code < 65535 ifTrue: [ > ... > > should be > > code < 65536 ifTrue: [ > > because 3-byte encoding can fit 16 bits, which is range > 0...65535 > but not > 0...65534 > > -- > Best regards, > Igor Stasenko.

April 2, 2014

NewListModel with multiple selection

by Martin Dias

Hi, I'm on latest Pharo 3 trying to display items in a list with multiple selection, and do something when the selection changes. So I did a try with NewListModel. The first I explored were the arguments passed to #whenSelectedIndexChanged:. I think they only inform about the last index selected but not about the multiple selection. So I decided to ask the list its #selectedItems, but the answer was not what I expected also. I'm not sure this is a bug to report or if I'm doing something wrong. I'll appreciate any help. Steps to reproduce: a) do it: me := NewListModel new. me items: (1 to: 2); beMultipleSelection; whenSelectedIndexChanged: [ self logCr: me selectedItems ]. me openWithSpec. => in Transcript I see: b) after a click on 1: #() c) after a shift+click on 2: #(1) d) inspecting "me selectedItems" ---> #(1 2) So, result in d) is fine but not b) and c). Thanks in advance, MartÃn PS: Before this, I tried to use a TreeModel and I found the issue discussed in"[Pharo-dev] [Spec] whenSelectedItemsChanged: on TreeModel".

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Goubier Thierry

Le 02/04/2014 13:58, phil(a)highoctane.be a Ã©crit : > Yes, RB would immensely benefit from some doc. +100. SmaCC makes use of RB, and there are a few things I'd need help with. > See other thread on that. I've seen it. Try to do a RB environment selecting what you want and loop on all classes over it, renaming them one by one. > I will start something pnce I get it wotking for my case. By the way, is there any news about Gisela Decuzzi work on a GUI for RB? 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

April 2, 2014