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

Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

by Ben Coman

On Thu, Feb 4, 2016 at 7:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > We are on âjust bugfixesâ since some time nowâ¦ I delayed the announcement because Epicea still needs to enter and we didnât manage to include it yet. > But wellâ¦ with the exception of Epicea, no new features will be included un Pharo 5â¦ just bugfixes (and we have a lot of bugfixes incomingâ¦ this release will be hard :( ) > > cheers, > Esteban Is it time then to move the current estebanlm/pharo-vm repository to the pharo-project/pharo-vm ? Maybe the existing pharo-project/pharo-vm "master" just gets retagged "preSpur" or "Last-V3" to avoid any delays needing to merge. Its not obvious the stability of your Spur64 tag with presumably development ongoing with that. We need a well defined point to tag a corresponding code-freeze for the VM, and ultimately a release50 tag. Then ongoing 64-bit development can continue on your topic branch. cheers -ben

Feb. 5, 2016

Re: [Pharo-dev] Best way to access icons?

by Ben Coman

On Fri, Feb 5, 2016 at 5:21 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I do not have the answer but I hate such patterns > > Smalltalk ui icons iconNamed: #protocolExtension. > > To me a tools using an icon should declare the icons as a ***local*** > ressources. +100. At a minimum this should probably be... self iconNamed: #protocolExtension. maybe supplied by a trait. Initially this might be... TGlobalIcons>>iconNamed: symbol ^ Smalltalk ui icons iconNamed: symbol but later be replaced by... TClassIcons>>iconNamed: symbol ^ IconContainer at: symbol and the tools would know how to work with those traits, e.g. in GTExplorer, a tab displaying the icons for a class. But IIUC traits can't add variables, but did I hear any object can be annotated? So could TClassIcons store a dictionary holding the icons as an annotation on the class? But we would need some way to store such resources with the package, in Monticello or otherwise. cheers -ben > We could imagine that there is a IconContainer and that as a tool I declare > that I want an icons and I install it on myself. > > | t | > t := Tool new. > ic := IconContainer for: #darkTheme. > t askAninnstallIcon: ic iconFor: #button. > > Then if the IconContainer changes, then it can notify its users to ask for a > new version of the icon. > > ic broadcastNewIcon: #button > > This way > > t does not have to use a plain bad global variable and does not care > about the global namespace. > t should only use local resources held in classVar for example. > > > Such Smalltalk ui icons is a dynamic global variable! > > Stef > > > > > > Le 4/2/16 17:00, Esteban Lorenzano a Ã©crit : > > Smalltalk ui icons iconNamed: #protocolExtension. > > Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦ they > will never be enough and wellâ¦ is like a monolithic vision. > Not that what we have is much better, but you can consider it an iteration > :) > > Esteban > > On 04 Feb 2016, at 16:19, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi > > For ages to access an icon we used: >> >> Smalltalk ui icons protocolPrivateIcon > > > Smalltalk ui icons returns an instance of ThemeIcons. > After refactoring (case https://pharo.fogbugz.com/f/cases/16651) all methods > to access icon (for example protocolPrivateIcon) were removed. > > ThemeIcons>>#doesNotUnderstand: aMessage converts message sent to iconNamed: > aMessage selector which works. > > BUT we have this all over the image: > <Screen Shot 2016-02-04 at 16.13.03.png> > > So, what is the best practice to access icons to use in application? > > Cheers, > Alex > > >

Feb. 5, 2016

Pharo mooc registration is available

by stepharo

https://www.france-universite-numerique-mooc.fr/courses/inria/41010/session…

Feb. 4, 2016

Re: [Pharo-dev] System Browser class pane strange behaviour

by stepharo

Le 3/2/16 14:32, Ben Coman a Ã©crit : > I have a talent for breaking things ;) ... me too but you are a lot better than me helping identifying the cause :) > Found some strange behaviour here... > > I open System Browser > select package AST-Core > select class ASTCache > make code pane dirty by typing 11111 in the class definition > select class ASTCacheReset > click <Discard> button > type 11111 > > --> oh! where did the buttons go? :) > > Bisecting finds it.... > exists in... 50564, 50510, 50440, 50400, 50384, 50380, 50378 > similar but located differently... 50300, 50368, 50376, 50377 > > still there... 50250, 50232, 50228 > not in... 50100, 50150, 50200, 50216, 50224, 50226, 50227 > > So it looks like this was introduced in build 50228... > * 16197 update and merge Rubric > * 16198 Add users button in message browser > * 16201 Remove unsent extension methods in System-Changes > http://forum.world.st/pharo-project-pharo-core-56107d-50228-td4842794.html > > and it was modified by build 50378... > * 16751 link invalidation: install cm directly for primitives and > optionCompileOnLinkInstallation > * 16729 Removing PluggableTextField from FT > http://forum.world.st/pharo-project-pharo-core-e8c312-50378-td4854678.html > > Logged https://pharo.fogbugz.com/default.asp?17520 > > cheers -ben > > P.S. thank you to those who made PharoLauncher work seemlessly with > pre-spur images

Feb. 4, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by stepharo

Thanks vincent!!!!! Le 4/2/16 16:25, Blondeau Vincent a Ã©crit : > I just tried to integrate and the tests are failing when reopening the image. Just added the opening of the session file at the right place and the closing of the file at the end of the critical section. Now, it works fine for me (under W7 of course ;): > > Name: Ombu-VincentBlondeau.191 > Author: VincentBlondeau > Time: 4 February 2016, 4:22:48.687273 pm > UUID: ebaf974e-9285-e147-bcaa-0049ff093ffe > Ancestors: Ombu-MartinDias.190 > > Vincent > >> -----Message d'origine----- >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Marcus Denker >> EnvoyÃ© : jeudi 4 fÃ©vrier 2016 15:19 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5 >> >> >>> On 04 Feb 2016, at 15:16, Damien Cassou <damien.cassou(a)inria.fr> wrote: >>> >>> Esteban Lorenzano <estebanlm(a)gmail.com> writes: >>> >>>> We are on âjust bugfixesâ since some time nowâ¦ I delayed the >> announcement because Epicea still needs to enter and we didnât manage to >> include it yet. >>>> But wellâ¦ with the exception of Epicea, no new features will be included >> un Pharo 5â¦ just bugfixes (and we have a lot of bugfixes incomingâ¦ this >> release will be hard :( ) >>> what is Epicea's integration status? >>> >> We have some strange problem on Windowsâ¦ the test on the build server >> fails after integrating it. >> >> Martin already fixed one problem, but my try yesterday failed again. >> >> Marcus >> > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Feb. 4, 2016

Re: [Pharo-dev] Best way to access icons?

by stepharo

Hi guys I do not have the answer but I hate such patterns Smalltalk ui icons iconNamed: #protocolExtension. To me a tools using an icon should declare the icons as a ***local*** ressources. We could imagine that there is a IconContainer and that as a tool I declare that I want an icons and I install it on myself. | t | t := Tool new. ic := IconContainer for: #darkTheme. t askAninnstallIcon: ic iconFor: #button. Then if the IconContainer changes, then it can notify its users to ask for a new version of the icon. ic broadcastNewIcon: #button This way t does not have to use a plain bad global variable and does not care about the global namespace. t should only use local resources held in classVar for example. Such Smalltalk ui icons is a dynamic global variable! Stef Le 4/2/16 17:00, Esteban Lorenzano a Ã©crit : > Smalltalk ui icons iconNamed: #protocolExtension. > > Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦ > they will never be enough and wellâ¦ is like a monolithic vision. > Not that what we have is much better, but you can consider it an > iteration :) > > Esteban > >> On 04 Feb 2016, at 16:19, Aliaksei Syrel <alex.syrel(a)gmail.com >> <mailto:alex.syrel@gmail.com>> wrote: >> >> Hi >> >> For ages to access an icon we used: >> >> Smalltalk ui icons protocolPrivateIcon >> >> >> Smalltalk ui icons returns an instance of ThemeIcons. >> After refactoring (case https://pharo.fogbugz.com/f/cases/16651 >> <https://pharo.fogbugz.com/f/cases/16651>) all methods to access icon >> (for example protocolPrivateIcon) were removed. >> >> ThemeIcons>>#doesNotUnderstand: aMessage converts message sent to >> iconNamed: aMessage selector which works. >> >> BUT we have this all over the image: >> <Screen Shot 2016-02-04 at 16.13.03.png> >> >> So, what is the best practice to access icons to use in application? >> >> Cheers, >> Alex >> >

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Nicolas Cellier

2016-02-04 13:09 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > > On 04 Feb 2016, at 10:26 , Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Le 04/02/2016 10:04, Nicolas Cellier a Ã©crit : > >> I don't understand broken history either. > >> Yes there can be .mcz name clashes but UUID history is stored together > >> in metadata no? > > > > Yes. > > > >> If some tool only trust .mcz name without checking UUID, consider it's a > >> bug, and let's correct it (there is some in Monticello Configuration > Map) > > > > Gofer. In fact, most of Monticello never checks the UUID, only > dependencies do, but this looks like a deprecated feature given how often > it is used. > > > >> Or is it the fact that some .mcz could be missing? > >> Consider this is a feature, MC tools are robust to missing .mcz (it's > >> just that you'll have to redo the merge if you lost a common ancestor). > > > > What? You really consider that a feature? > > > >> Or is it the fact that some repository might contain only a slice of > >> history? > >> This is another feature... You can view all the versions in a collection > >> of repositories without needing to replicate. > > > > Understandable in theory. Unworkable over time and change (repositories > disappear and die, and this stops working) > > > >> You can replicate if you want but it's not mandatory and completely > >> orthogonal. > >> So yes, this information - the list or repositories you want to consider > >> - has to be stored separetely and this can sound quite unconventional. > >> But IMO, it's an important feature: it gives much resilience for a very > >> low investment. > >> And that also mean that you can hardly break things (have unconsistent > >> history). > > > >> Maybe when you say broken, you mean not 100% git compatible? > > > > No, what I say is true mcz inconsistent history (missing versions making > merges very unreliable, basically). > > > > I describe a while ago a case where, thanks to mcz features, I couldn't > merge a small change done to Roassal without generating a ton of conflicts. > I moved the three needed mcz(s) to git (the change ancestor, the change, > and the current head), did git merge and had no conflicts. > > > > If you consider those features, then I disagree. > > Also, the ancestry of all packages in Pharo Core was truncated a few years > back, which also screwed up merging*. > I don't think anyone looked into why it happened. > > Cheers, > Henry > > * > http://forum.world.st/FogBugz-Case-Issue-12776-Tools-Cancelling-quot-Previo… > Henry, you perfectly nailed it... Break it first/throw away/replace is not allways a winning strategy. We are ready to re-integrate source code in image at the price of a few MBytes, but it was urgent to throw history away BEFORE we even get a working replacement... Here is a mail i did not send because I didn't want to be to start the year too negativily: ---------------------------- "snip... was about a regexp bug that I tried to bisect... (a post of january 2015) So I wanted to be informed of the other changes going on since plenty of interesting things are going on in Pharo. Ah hem, but the package has been renamed and the 'version history' menu is there only to show me that history has been purposely expunged from image... It became such a useless menu now, that i think you could as well remove it. Spawning the 4.0 repository and using the History button, reveals a bit of history this time, sounds like the 3.0 bits... Notice in attachment how the versions 22 and 23 which are in the 3.0 repository seems to be missing... Ah, no this is a brand new strategy for presenting the merged branches... without any care for a common ancestor. Notice in other attachment how it's not allways been so. And what if I want to look a bit further behind? Shall I go outside the image and browse github now? The web UI did absolutely not work for me, the 3.0 history is cut there too, and blame only reveals me the name of Jenkins... Git command line might have done a better work, but anyway, doesn't the I in IDE stands for Integrated? I won't know because at this stage i gave up. snip... that's enough ranting "

Feb. 4, 2016

Re: [Pharo-dev] [Vm-dev] Simple versus Recursive Mutexes

by Denis Kudriashov

Hi Ben. 2016-02-04 18:16 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > SimpleMutex>>critical: aBlock > Processor activeProcess == owner > ifTrue: [self error: 'recursive locks will kill you' ]. > ^ super critical: aBlock > This can be easily implemented with current primitive (I use inverted version here): SimpleMutex>>critical: aBlock acquiredHere := lock acquire. acquiredHere ifFalse: [self error: 'recursive locks will kill you' ]. ... So what you want to change?

Feb. 4, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Martin Dias

Wow, thank you very much for the contribution Vincent! I'm analyzing your changes. Martin On Thu, Feb 4, 2016 at 12:25 PM, Blondeau Vincent < vincent.blondeau(a)worldline.com> wrote: > I just tried to integrate and the tests are failing when reopening the > image. Just added the opening of the session file at the right place and > the closing of the file at the end of the critical section. Now, it works > fine for me (under W7 of course ;): > > Name: Ombu-VincentBlondeau.191 > Author: VincentBlondeau > Time: 4 February 2016, 4:22:48.687273 pm > UUID: ebaf974e-9285-e147-bcaa-0049ff093ffe > Ancestors: Ombu-MartinDias.190 > > Vincent > > > -----Message d'origine----- > > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > > Marcus Denker > > EnvoyÃ© : jeudi 4 fÃ©vrier 2016 15:19 > > Ã : Pharo Development List > > Objet : Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5 > > > > > > > On 04 Feb 2016, at 15:16, Damien Cassou <damien.cassou(a)inria.fr> > wrote: > > > > > > Esteban Lorenzano <estebanlm(a)gmail.com> writes: > > > > > >> We are on âjust bugfixesâ since some time nowâ¦ I delayed the > > announcement because Epicea still needs to enter and we didnât manage to > > include it yet. > > >> But wellâ¦ with the exception of Epicea, no new features will be > included > > un Pharo 5â¦ just bugfixes (and we have a lot of bugfixes incomingâ¦ this > > release will be hard :( ) > > > > > > what is Epicea's integration status? > > > > > We have some strange problem on Windowsâ¦ the test on the build server > > fails after integrating it. > > > > Martin already fixed one problem, but my try yesterday failed again. > > > > Marcus > > > > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Feb. 4, 2016

Re: [Pharo-dev] Best way to access icons?

by Chris Cunningham

On Thu, Feb 4, 2016 at 7:19 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi > > For ages to access an icon we used: > >> Smalltalk ui icons protocolPrivateIcon > > > Smalltalk ui icons returns an instance of ThemeIcons. > After refactoring (case https://pharo.fogbugz.com/f/cases/16651 > <https://pharo.fogbugz.com/f/cases/16651>) all methods to access icon > (for example protocolPrivateIcon) were removed. > > ThemeIcons>>#doesNotUnderstand: aMessage converts message sent to iconNamed: aMessage > selector which works. > > BUT we have this all over the image: > [image: Inline image 1] > > So, what is the best practice to access icons to use in application? > What if a class was created, MethodProtocol, that encapsulated this behaviour? The tools could identifiy which protocol by String (as in this method), with a 'default' or 'bucket' protocol for ones that aren't previously identified. Then, for categoryIconFor: string would either identify the methodProtocol instance and ask #icon. It might delegate however it likes - or cache it's particular icon. Just a thought. -cbc > > > Cheers, > Alex > >

Feb. 4, 2016