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

[Ann] New version of Mocketry 3.0

by Denis Kudriashov

I am glad to present simplest mocks for Pharo. In this version Mocketry is dramatically improved and changed. I try to provide most simple way to stub any message to any object and to verify any occurred behaviour. You can read full details in my blog http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html Here is short example: mock := Mock new. mock *stub* someMessage *willReturn:* 1000. mock someMessage should be: 1000. mock *should got* someMessage. mock *should not* *got* anotherMessage. rect := 0@0 corner: 2@3. rect *stub* width willReturn: 1000. rect area should be: 3000 "area = width * height". rect *should got* width.

April 6, 2016

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

by Sven Van Caekenberghe

Fix for review: === Name: STON-Core-SvenVanCaekenberghe.71 Author: SvenVanCaekenberghe Time: 6 April 2016, 2:22:24.782251 pm UUID: 64b8b741-365e-41fe-aa98-565e33ca5d24 Ancestors: STON-Core-SvenVanCaekenberghe.70 Fix a bug where STONReferences occurring as keys in Dictionaries or elements in Sets caused those to be unhealthy after materialization. Thx to Peter UhnÃ¡k for reporting this issue. Add 3 new unit tests to STONReaderTests #testDictionaryWithReferenceKeys #testSetWithReferenceElements #testDeepStructure Fix Details change the implementation of STONReader>>#processSubObjectsOf: from iterative to recursive (see version 39 of 29 November 2012, this might be a functional regression, see #testDeepStructure; cleanup of stack instance variable for later) so that #stonProcessSubObjects: can be overwritten with code being executed before or after full reference resolution imho, recursion stack depth will be equal during both writing and reading, and should be acceptable. overwrite #stonProcessSubObjects: in Dictionary and Set to #rehash at the end, but only when needed (minimal optimalization, see Dictionary>>#containsStonReferenceAsKey and Set>>#containsStonReference) === Name: STON-Tests-SvenVanCaekenberghe.63 Author: SvenVanCaekenberghe Time: 6 April 2016, 2:22:45.01986 pm UUID: 0beb2322-b81a-46ee-a0e2-6648a808774a Ancestors: STON-Tests-SvenVanCaekenberghe.62 (idem) === > On 06 Apr 2016, at 14:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Diction… > > fix coming > >> On 05 Apr 2016, at 13:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 05 Apr 2016, at 13:02, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> >>> >>> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com>: >>> >>> >>> On 05/04/2016 12:09, Sven Van Caekenberghe wrote: >>> >>>> Like I said, it is a hashing issue, sometimes it will be correct by accident. >>>> >>>> I hope you did not have to much trouble with this bug, I guess it must have been hard to chase. >>>> >>>> Is it urgent ? >>>> >>>> I probably can give you a quick fix, but I would like to think a bit more about this, since rehashing each materialised dictionary seems expensive. >>>> >>>> >>>> >>> >>> Hi Sven, >>> >>> I got the same kind of problem in a personal application. >>> >>> I use Sets that I serialize and I had a lot of trouble because sometimes >>> some action had strange behaviours. >>> >>> For example in a set with element `aSet remove: aSet anyOne` raised 'XXX >>> not found in aSet'. >>> >>> I am glad to hear that it is a Ston issue and not me that used sets in a >>> bad way :) >>> >>> For me too it is not urgent since I have a not of university work for >>> the moment. >>> >>> >>> >>> How are hashed collections created/filled during ston-parsing ? >>> If the position in a hashed collection is created by a ston-reference, that is later replaced by the "real" object, >>> the index in the dictionary (or other hashed collections) may be wrong. >> >> Yes, that is indeed it, Nicolai. >> >> But I would like to try to minimise the rehashing as it seems expensive. But first I need a more reliable failure. >> >>> -- >>> Cyril Ferlicot >>> >>> http://www.synectique.eu >>> >>> 165 Avenue Bretagne >>> Lille 59000 France >

April 6, 2016

Re: [Pharo-dev] [Pharo-users] STON materialization corrupts a dictionary if the keys are references

by Sven Van Caekenberghe

https://pharo.fogbugz.com/f/cases/17946/STON-materializes-unhealthy-Diction… fix coming > On 05 Apr 2016, at 13:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 05 Apr 2016, at 13:02, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2016-04-05 12:32 GMT+02:00 Cyril Ferlicot Delbecque <cyril.ferlicot(a)gmail.com>: >> >> >> On 05/04/2016 12:09, Sven Van Caekenberghe wrote: >> >>> Like I said, it is a hashing issue, sometimes it will be correct by accident. >>> >>> I hope you did not have to much trouble with this bug, I guess it must have been hard to chase. >>> >>> Is it urgent ? >>> >>> I probably can give you a quick fix, but I would like to think a bit more about this, since rehashing each materialised dictionary seems expensive. >>> >>> >>> >> >> Hi Sven, >> >> I got the same kind of problem in a personal application. >> >> I use Sets that I serialize and I had a lot of trouble because sometimes >> some action had strange behaviours. >> >> For example in a set with element `aSet remove: aSet anyOne` raised 'XXX >> not found in aSet'. >> >> I am glad to hear that it is a Ston issue and not me that used sets in a >> bad way :) >> >> For me too it is not urgent since I have a not of university work for >> the moment. >> >> >> >> How are hashed collections created/filled during ston-parsing ? >> If the position in a hashed collection is created by a ston-reference, that is later replaced by the "real" object, >> the index in the dictionary (or other hashed collections) may be wrong. > > Yes, that is indeed it, Nicolai. > > But I would like to try to minimise the rehashing as it seems expensive. But first I need a more reliable failure. > >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 165 Avenue Bretagne >> Lille 59000 France

April 6, 2016

Re: [Pharo-dev] TxText model

by Nicolai Hess

Nice! 2016-04-06 12:18 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > On 06-04-16 10:36, Nicolai Hess wrote: > >> In what use cases is this a problem ? (Paragraph and DisplayScanner have >> good support for justified text (left / right / center), indentation >> wrapping and (I don't know if this works in pharo anymore but squeak had) >> even filling text in arbitary shaped polygons ( that was pretty cool). And >> even for text of different size and with different emphasis. >> > > |t1 t2 ball page| > page := Morph new. > page bounds: (100@100 corner: 300@300). > page color: Color gray. > t1 := TextMorph new. > t1 autoFit:false. > t1 bounds: (105@105 corner: 195@295). > t1 backgroundColor: Color white. > t1 occlusionsOnOff. > page addMorph: t1. > t2 := TextMorph new. > t2 autoFit: false. > t2 bounds: (205@105 corner: 295@295). > t2 backgroundColor: Color white. > t2 occlusionsOnOff. > page addMorph: t2. > t1 setSuccessor: t2. > t2 setPredecessor: t1. > ball := CircleMorph new. > ball bounds: (160@160 corner: 240@240). > page addMorph: ball. > page openInWorld >

April 6, 2016

Re: [Pharo-dev] TxText model

by Stephan Eggermont

On 06-04-16 10:36, Nicolai Hess wrote: > In what use cases is this a problem ? (Paragraph and DisplayScanner > have good support for justified text (left / right / center), > indentation wrapping and (I don't know if this works in pharo anymore > but squeak had) even filling text in arbitary shaped polygons ( that > was pretty cool). And even for text of different size and with > different emphasis. |t1 t2 ball page| page := Morph new. page bounds: (100@100 corner: 300@300). page color: Color gray. t1 := TextMorph new. t1 autoFit:false. t1 bounds: (105@105 corner: 195@295). t1 backgroundColor: Color white. t1 occlusionsOnOff. page addMorph: t1. t2 := TextMorph new. t2 autoFit: false. t2 bounds: (205@105 corner: 295@295). t2 backgroundColor: Color white. t2 occlusionsOnOff. page addMorph: t2. t1 setSuccessor: t2. t2 setPredecessor: t1. ball := CircleMorph new. ball bounds: (160@160 corner: 240@240). page addMorph: ball. page openInWorld

April 6, 2016

Re: [Pharo-dev] [ANN] MessageFlowBrowser updated for Pharo 5 + new video

by Sven Van Caekenberghe

> On 06 Apr 2016, at 12:13, phil(a)highoctane.be wrote: > > Didn't know about the tool. Cool thing! +1 > Phil > > On Wed, Apr 6, 2016 at 10:54 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > MessageFlowBrowser was updated for Pharo 5 (no deprecation warnings anymore). > > Also enjoy the new video: > > http://youtu.be/DRd_bzGocQg > > Have fun > T. > >

April 6, 2016

Re: [Pharo-dev] [ANN] MessageFlowBrowser updated for Pharo 5 + new video

by phil＠highoctane.be

Didn't know about the tool. Cool thing! Phil On Wed, Apr 6, 2016 at 10:54 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > MessageFlowBrowser was updated for Pharo 5 (no deprecation warnings > anymore). > > Also enjoy the new video: > > http://youtu.be/DRd_bzGocQg > > Have fun > T. > >

April 6, 2016

Re: [Pharo-dev] [Pharo5] [Issue tracker] Acton needed: Check issues tagged Pharo5

by Marcus Denker

Hi, We are at 101 issues open that are tagged for Pharo5: https://pharo.fogbugz.com/f/filters/125/5-0-Al At the end of *this* week, we will move all issues to âlaterâ that are of the priority "5 â Fix If Time" Please have a look and if you think that an issue is more important, increase the priority. Marcus > On 01 Apr 2016, at 10:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The plan is to release Pharo5 soon (End of April, if possible). > > We have now 144 issues tagged for Pharo5, 41 of those âmust fixâ or higher. > > We need to go though all the 144 issues and decide: > > âIs this bug to bad that it does not allow for a release?â > > If not, we should move it to milestone âLaterâ. > > https://pharo.fogbugz.com/f/filters/125/5-0-All > > It would be good if either the original submitter or people involved in the > discussion of those issues would have a look and help with taking this > decision. > > (And of course, if you have potentialy show stopping bugs that are not > in the list, this is the time to add themâ¦) > > Marcus

April 6, 2016

Re: [Pharo-dev] TxText model

by phil＠highoctane.be

On Wed, Apr 6, 2016 at 11:02 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 6 April 2016 at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hi >> >> 2016-04-06 9:07 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> What are the main problems with Text, Paragraph, ... and other old >>> TextComponents? >> >> >> I don't want to write crappy words. But to understand what was wrong you >> can try with them: >> >> - remove blinking cursor for specific morph instance >> - hide selection or change it color for specific morph instance >> - implement validation for input when only digits are allowed >> - implement masked fields >> - try to make all this composable >> >> It seems that first two items are really simple tasks. But it is huge >> pain and hacks at the end. >> > > Yes, Denis, that was i did not mentioned. > But as i said my main focus was not trying to fix all of the above , but > to enable vector-based rendering for text. The rest was coming as a bonus > and future work. > Because else, all of it worth nothing if you cannot even render text with > Athens.. > > I tried to do some decent hypertext and noticed that features that allowed to do this in Squeak were scrapped (for good reason, but still). And yeah, for long chunks of text... that's a big no no. Note that ParagraphEditor gets recreated all the time. And that rendering of text when there is bold text + italic + normal just didn't aligned properly on the computed text metrics (with StrikeFont at the time, I do not know if this is solved with TrueType fonts and Cairo). Another pain is the styling of text where the only styler we have is the SHSt80Styler (class name out of my mind, need to check) and that's a huge pain to support other stylings. Doru did something for Pillar at one point (apparently using PetitParser and island parser). I am also looking at Grafoscopio but need more time to understand what's in it. Still TxText is a good thing to have. We must have proper text management for such an OO platform. They manage to do things in Jetbrains tools (IDEA, WebStorm...) and that's pure Java/Swing (from what I know having worked extensively in Swing at one point is that internals of Swing are also messy, but less, and in other ways) Doable then. Big hopes in Bloc/Brick here, will try to do my ideas again with them. Phil > -- > Best regards, > Igor Stasenko. >

April 6, 2016

Re: [Pharo-dev] [ANN] MessageFlowBrowser updated for Pharo 5 + new video

by Thierry Goubier

2016-04-06 10:54 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > MessageFlowBrowser was updated for Pharo 5 (no deprecation warnings > anymore). > A nice example of an infinite tree one should not do a full text search in :) Thierry > > Also enjoy the new video: > > http://youtu.be/DRd_bzGocQg > > Have fun > T. > >

April 6, 2016