- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 2/4/16 9:48 AM, Esteban A. Maringolo wrote: > 2016-02-04 14:39 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > >> Pertinent is Joel's description of how Microsoft Excel's tipping point >> [1] in competing against Lotus123 was when it became able to export to >> Lotu123 format. Making it easy for people to move from git back to >> Monticello lower the barrier for entry for people to use git. > I always remember this article, but regarding Pharo and Git (or any > other file based SCM) I always thought about it the other way, it > is... the tipping point could be a seamless/smooth adoption of file > based SCMs, with git being the most prominent case. > > Esteban A. Maringolo > ... and both are important:)

Feb. 4, 2016

Re: [Pharo-dev] [ANN] Pomodoro for Pharo 2.0

by ipstone

Hello, First time user of Pharo - I just got pomodoro up running, but how to close it? Thanks! -- Ipstone -- View this message in context: http://forum.world.st/ANN-Pomodoro-for-Pharo-2-0-tp4678427p4875915.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

On 2/4/16 9:39 AM, Ben Coman wrote: > On Fri, Feb 5, 2016 at 1:08 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> >> On 2/3/16 10:53 PM, Thierry Goubier wrote: >>> Le 03/02/2016 23:58, Dale Henrichs a Ã©crit : >>>> >>>> >>>> On 02/03/2016 02:34 PM, Thierry Goubier wrote: >>>>> Le 03/02/2016 22:51, Eliot Miranda a Ã©crit : >>>>>> >>>>>> >>>>>> On Wed, Feb 3, 2016 at 12:54 AM, Thierry Goubier >>>>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>>>>> >>>>>> Hi Eliot, >>>>>> >>>>>> Le 02/02/2016 21:54, Eliot Miranda a Ã©crit : >>>>>> .... >>>>>> >>>>>> >>>>>> No it's /not/ the end of the story. The essential part of the >>>>>> story is >>>>>> how Monticello remains compatible and interoperable between >>>>>> dialects. I >>>>>> haven't seen you account for how you maintain that >>>>>> compatibility. As >>>>>> far as I can tell, you propose replacing the Monticello >>>>>> metadata >>>>>> with >>>>>> that from git. How do I, as a Squeak user with Monticello, >>>>>> ever >>>>>> get to >>>>>> look at your package again? As I understand it, moving the >>>>>> metadata >>>>>> from Monticello commit time to git means that the metadata is >>>>>> in a >>>>>> format that git determines, not Monticello. >>>>>> >>>>>> >>>>>> Yes. See below why. >>>>>> >>>>>> So I don't understand how on the one hand you can say "The >>>>>> Monticello >>>>>> metadata in a git repository is redundant and leads to >>>>>> unnecessary >>>>>> commit conflicts -- end of story ....", which implies you >>>>>> want to >>>>>> eliminate the Monticello metadata, and on the other hand you >>>>>> say >>>>>> you're >>>>>> keeping the Monticello metadata. I'm hopelessly confused. How >>>>>> does the >>>>>> Monticello metadata get reconstituted if it's been thrown away? >>>>>> >>>>>> What happens to the metadata in the following workflow? >>>>>> >>>>>> load package P from Monticello repository R into an image >>>>>> change P, commit via git to local git repository G >>>>>> load P from G into an image >>>>>> store P to R via Monticello >>>>>> >>>>>> >>>>>> It's not a scenario I've specifically worked on, but all the tech >>>>>> is >>>>>> implemented / implementable to do that perfectly. >>>>>> >>>>>> The only thing that is problematic there is that the only safe >>>>>> history is the one generated from git... there are so many MC >>>>>> packages with broken history that, on mcz packages, you have to >>>>>> admit that it's not safe to base things on their history. >>>>>> >>>>>> >>>>>> I'm sorry but I don't accept that. In the Squeak trunk we have history >>>>>> in our mczs that is correct. Certainly in VMMaker.oscog I have history >>>>>> that goes back a long time. If bugs have broken history then efforts >>>>>> should be made to repair that history. But you can't just write off >>>>>> Monticello history like that. >>>>> >>>>> I don't. You presuppose. >>>>> >>>>> I write tools that work with Monticello repositories, not just yours. >>>>> I have to do with what is given to me. On a general level, as a mcz >>>>> user, I'll just have to consider that you are as susceptible to be >>>>> trusted as with any other mcz producer. This means not much... >>>> >>>> ... And this is the reason why I am inclined to favor option 3, which >>>> records the package version history as it existed at the point it was >>>> copied into a git repo. When copied back out from the git universe, >>>> create a version history that starts with the original version history >>>> and generates a history of the package in git .... >>> >>> Which is not very difficult to do given how GitFileTree is implemented. >>> And I agree this may well be the way to go. But ... >>> >>>> Correct or not, the Monticello version history should be preserved .... >>> >>> I wonder about that. The property of the Monticello version history is >>> that it has value when you can access the versions listed in it. If you mix >>> repositories like that, unless you maintain a link to the previous mcz >>> repository, pre-git versions can't be accessed. So, most of the time, what >>> we do with a project moved under git is to clone the previous repository, >>> not take just the current head. >>> >>> (you'll notice, by the way, that vcs usually work that way when moving >>> from, say, CVS to git - you move the entire repository, not just the latest >>> version). >>> >>> In short, the question would really be: >>> 1- should we invest into making that integration of past history a selling >>> point (but I foresee issues down the road; I've only described one so far, >>> and I have seen others) >>> or >>> 2- into making a better "clone" of a package history, timestamps and >>> everything when moving a complete repository to git? >>> >>> Honestly, I'd consider 1- to be the easiest to implement. 2- there is >>> already some code floating around. >> Thierry, >> >> My take on this is that we are not trying to "fix" Monticello. >> >> The developers who prefer to use Monticello should continue to use >> Monticello and the existing Monticello tools should continue to be >> available. Any new formats should provide a migration path from Monticello >> and any new tools like a `project list` tool should accommodate projects >> based on both git and Monticello repositories. >> >> This particular branch of the conversation has been aimed at trying to >> resolve the tension that has been created by including Monticello metadata >> in FileTree repositories and I think that "option 3": including past history >> in the FileTree repository, but not updating the version history for each >> git commit is a workable compromise --- there are always "issues down the >> road" whether or not we see them and that shouldn't keep us from trying to >> evolve:) >> >> FileTree was invented (props to Otto Behrens) to smoothly integrate the use >> of disk-based repositories into a Monticello development environment >> dominated by Monticello tools. >> >> Thierry your work building on the original FileTree has gone a long way >> towards making git a viable development option for Pharo. >> >> I think that you'd agree that the next step of evolution for "git-based" >> development involves improved tool support and I would think that we should >> turn our focus in that direction... >> >> Dale >> > Pertinent is Joel's description of how Microsoft Excel's tipping point > [1] in competing against Lotus123 was when it became able to export to > Lotu123 format. Making it easy for people to move from git back to > Monticello lower the barrier for entry for people to use git. > > [1] Scroll down to the second "tipping point" > http://www.joelonsoftware.com/articles/fog0000000052.html > That was the original rationale for including the Monticello metadata. Unfortunately the implementation I chose interferes with the natural use of git, so an alternate solution is needed. I think the technology is present to be able to implement "option 3" in relatively short order and we can look forward to this in a future release of FileTree[1]. But we also need to focus on improving the "git" support by the tools so that developers can leverage some of the advantages that "git" brings to the tble... developers need to be able to see version history at the package, class, and method level; they need to be able perform the "standard" git operations (commit, checkout, branch, diff, push, pull ...) without leaving the image; and they need to be able to do git merges in the image .... At least that's my opinion:) Dale [1] https://github.com/dalehenrich/filetree/issues/177

Feb. 4, 2016