- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Contributing to Pharo

by Esteban A. Maringolo

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

Feb. 4, 2016

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

by Stephan Eggermont

On 04-02-16 17:55, Esteban Lorenzano wrote: > >> On 04 Feb 2016, at 17:38, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 04-02-16 17:00, Esteban Lorenzano wrote: >>> Smalltalk ui icons iconNamed: #protocolExtension. >>> >>> Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦ >> >> Why do you see that as a problem? For me the problem is more the trainwreck. > > because then you have a fixed number of icons and you cannot dynamically load more. Sorry, I don't get your point. We have extension methods, so dynamically adding more works. I usually prefer selector access over dictionary, when possible. Where is this better? Please elaborate. Stephan

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Ben Coman

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 cheers -ben

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Stephan Eggermont

On 04-02-16 17:22, Dale Henrichs wrote: > Stephan, > > Have you described this anywhere? Not very much http://forum.world.st/Overhead-in-mczs-MCVersionInfo-td4869374.html MCHttpRepository location: 'http://smalltalkhub.com/mc/StephanEggermont/MonticelloProjects/main' user: '' password: '' Jan 5. on Slack Stephan Eggermont 20:21 So I deduplicated the ancestry, putting the UUID of missing ancestors in place of the MCVersionInfo 20:25 123 MB instead of 1.2 GB, compressed 70.8 MB 20:26 The whole history of VMMaker Thierry Goubier 20:34 With all versions? Stephan Eggermont 20:34 missing 2, 20:35 and only those on source.squeak.org Stephan Eggermont 20:35 CompactVMMaker.fl.tar.gz 67MB Binary Click to download Thierry Goubier 20:37 I'd be interested to see how large would be the git repository containing that. Maybe I'll make a try. Stephan Eggermont 20:42 Nice compression factor. package cache of 2725 items, 6.1 GB Thierry Goubier 20:44 ! Thierry Goubier 21:21 Then I can't test the git thing. Not enough HD space on the Chromebook.

Feb. 4, 2016

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

by Ben Coman

On Wed, Feb 3, 2016 at 2:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Ben, > > On Tue, Feb 2, 2016 at 9:54 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> While we are in the process of revising the Mutex infrastructure [1] >> to use dedicated primitives rather than rely on counting via a >> semaphore, I want to raise the question of simple versus recursive >> mutexes. >> >> This isn't something I know much about, except that some people >> strongly believe recursive mutexes are evil, including David Butenhof >> who apparently was the guy who added recursive mutexes to POSIX "on a >> dare [...] but nobody was supposed to use recursive mutexes." [1]. >> >> There are two interesting discussion on stockoverflow [2][3]. But btw >> I disagree with Tall Jeff [3] says "The difference between a recursive >> and non-recursive mutex has to do with ownership. " I think he >> confuses a simple-mutex and binary-semaphore, as do a some commenters. >> >> "Prefer Simple Mutex Over Recursive Mutex" [4] demonstrates some >> performance considerations and advises "a recursive mutex is dangerous >> because you lose sense of locking scope. It costs more than a simple >> mutex." >> >> "Recursive Locks Will Kill You!" [5] provides some thread safety >> guidelines. >> >> Finally, there is a paper "Ad Hoc Synchronization Considered harmful" >> [6], which I haven't read yet since I wanted to get this post out >> before heading to bed, but I hope to tomorrow. >> >> >> [1] http://www.zaval.org/resources/library/butenhof1.html >> [2] http://stackoverflow.com/questions/2415082/when-to-use-recursive-mutex >> [3] >> http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recur… >> [4] >> http://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/ >> [5] >> http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/ >> [6] https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Xiong.pdf >> >> >> So our existing Mutex implementation happens to be recursive, and I'm >> not suggesting we change that. However if we should consider *not* >> baking the *assumption* of recursion into the primitives, so the same >> primitives could *also* be used for a SimpleMutex class. The logic to >> provide recursion for Mutex is only [ owner = activeProcess ] which is >> easily done in-image. >> >> So I propose introducing aquire/release primitives based off the >> existing critical section primitives with the recursion removed. > > > We have two sets of primitives, the queueing semaphore ones, signal and > wait, #85 & #86, which are not recursive, and new ones, #185, #186 & #187 > that support ownership, and hence support recursion. It makes no sense to > remove the recursion support. That's what the primitives are for, to > provide ownership support as efficiently as possible. Please don't be led > by the problems others may have in other systems, and instead be led by how > we're doing. Squeak and Pharo (and Smalltalk) have had recursive owned > critical sections for decades and no one (e.g. from demanding industrial > control applications) has complained that these recursive critical sections > are problematic. I respect your deep experience, but there is an engineering principle that "just because it works, doesn't mean its correct. It may just be reinforcing some misconceptions" ;) Several reasons why people may not complain... 1. the expectation its been there so long that its correct 2. the expectation expert people worked on it so its correct 3. subtle bugs remain latent or trigger infrequently, thus hard to isolate 4. when bugs arise, they are fixed pragmatically without deeper philosophical consideration 5. coincidently other good programming practices avoided problematic situations 6. Threads run concurrently and co-operatively, so maybe in practice there are less issues than a parallel and pre-emptive systems. > Remember we have closures and hence ensure: and good > unwinding support. I take it you refer to ensuring locks are required and released the same number of times. This is not related to my concern. > The new primitives give us a streamlined and hack-free > implementation which doesn't depend on the niceties of what are suspension > points as do the pre-primitive implementations. So I see no rationale for > gelding these primitives. I would think a thread doing an in-image (owner = activeProcess) test would be unaffected by suspension points since it doesn't change any state and only the same thread would have set owner via the primitive. > Show me a paper on a Smalltalk app that says "recursive locks will kill you" > and I'll reconsider, but in thirty years I've not seen a complaint. I cannot. There seems very limited literature on concurrency in Smalltalk. It was hard coming up with a concise example of my own, so its a bit contrived, but here goes... Imagine an invariant requirement for a value always be even. Each time work is done, the value increases monotonically. However the value must be odd while the work is done. Object subclass: #A instanceVariableNames: 'alwaysEven relaxInvariant' classVariableNames: '' package: 'ANExample' A>>initialize relaxInvariant := Mutex new. alwaysEven := 0. A>>logMe: aString Transcript crShow: self className, aString A>>doCriticalWork self logMe: ' did some work' A>>displayNext relaxInvariant critical: [ alwaysEven := alwaysEven + 1. self doCriticalWork. alwaysEven := alwaysEven + 1 ]. self logMe: ' produced even number ' , self alwaysEven printString A>>alwaysEven ^ relaxInvariant critical: [ alwaysEven ] Now "(A new) displayNext; displayNext" produces... A did some work A produced even number 2 A did some work A produced even number 4 and all is well. Now assume that exists deep in the system library, programmed by a core-dev. So Along I come as and end-user and for my own project need B just like A but additionally need to do a bit more work. A subclass: #B instanceVariableNames: '' classVariableNames: '' package: 'ANExample' B>>doCriticalWork super doCriticalWork. self logMe: ' produced odd number ' , (self alwaysEven + 1) printString. Read that last line again. Its fairly obvious what behaviour to expect. Now "(B new) displayNext; displayNext" produces... B did some work B produced odd number 2 B produced even number 2 B did some work B produced odd number 4 B produced even number 4 So do I dare complain the mutex that was expected to protect the invariant is broken? Or do I assume its my own stupid fault for not fully comprehending the internals of the system library? Here the aberrant behaviour is clear, but in a complex system the defect may subtly corrupt data so it doesn't misbehave until later with the effect distant from the cause. Alternatively, using a non-recursive mutex... Mutex subclass: #SimpleMutex instanceVariableNames: '' classVariableNames: '' package: 'Kernel-Processes' SimpleMutex>>critical: aBlock Processor activeProcess == owner ifTrue: [self error: 'recursive locks will kill you' ]. ^ super critical: aBlock B subclass: #C instanceVariableNames: '' classVariableNames: '' package: 'ANExample' C>>initialize relaxInvariant := SimpleMutex new. alwaysEven := 0. Now "(C new) displayNext; displayNext" produces... C did some work Error: recursive locks will kill you So here it fails *early*. This may be good for some folks and bad for others, but one should have the choice. ;) I feel like saying that it would be better for a concurrency neophyte to start with the rigour of a SimpleMutex and stick with it as long as possible, for what they would learn along the way about cases a recursive lock is really needed. But really I don't know, or whether I'd be just snatching arguments to support my view. Now I don't propose to change the existing primitiveXXXCriticalSection, but it seems the logic for those is reverse for the #aquire message that Dennis wants to use ( "lock acquire" currently will be returning false when it aquires the lock) . I thought you'd hinted it might be possible to add some primitives such that "lock acquire" returns true, and maybe those could be non-recursive. We would still need to evaluate what the actual performance impact was. > The complaints I have seen are > > - queueing Semaphores should or should not be priority queues, depending on > requirements. In VW #85 & #86 were changed so that Semaphore is a priority > queue. This has been good for some folks but bad for others. One should > have the choice, but the current Squeak/Pharo/Smalltalk-80 default that they > are /not/ priority queues is the right default > > - we suffer from deadlock due to priority inversion. A high-priority > process spinning trying to gain access to a lock held by a low-priority > process can shut out the low-priority process from releasing its lock. This > is minimised by the new recursive lock primitives, but may still be a > possibility. We should work on creating test cases. Positively the test > cases that Andreas developed for me at Qwaq when I developed the recursive > locking primitives no longer fail. I've not had time to investigate. Can you provide these? Sounds like a puzzle I might like to chew on. > > - preempting a lower-priority process by a higher-priority process causes > the preempted process to yield to others at the same priority. This is a > bug which has been fixed in VW and in Cog. It is an option in Cog but it > should be enabled. See SmalltalkImage>>processPreemptionYields. Smalltalk > processPreemptionYields should answer false. In 50564, Smalltalk vm processPreemptionYields --> true. cheers -ben

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Dale Henrichs

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

Feb. 4, 2016

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

by Aliaksei Syrel

Thanks, Esteban :) As compromise > Smalltalk ui icons iconNamed: #something is ok for now. Cheers Alex On Thu, Feb 4, 2016 at 5:55 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 04 Feb 2016, at 17:38, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > > On 04-02-16 17:00, Esteban Lorenzano wrote: > >> Smalltalk ui icons iconNamed: #protocolExtension. > >> > >> Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦ > > > > Why do you see that as a problem? For me the problem is more the > trainwreck. > > because then you have a fixed number of icons and you cannot dynamically > load more. > You can create methods ad-hoc, but I do not like this in generalâ¦ and you > do not have any gain between doing: > > Smalltalk ui icons iconNamed: #something > > and doing: > > Smalltalk ui icons somethingIcon. > > ThemeIcons>>#somethingIcon > ^ self iconNamed: #something > > > So yesâ¦ adding a selector-per-icon is not recommended because it does not > scales. > > Esteban > > > > > Stephan > > > > > > > > >

Feb. 4, 2016

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

by Esteban Lorenzano

> On 04 Feb 2016, at 17:38, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 04-02-16 17:00, Esteban Lorenzano wrote: >> Smalltalk ui icons iconNamed: #protocolExtension. >> >> Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦ > > Why do you see that as a problem? For me the problem is more the trainwreck. because then you have a fixed number of icons and you cannot dynamically load more. You can create methods ad-hoc, but I do not like this in generalâ¦ and you do not have any gain between doing: Smalltalk ui icons iconNamed: #something and doing: Smalltalk ui icons somethingIcon. ThemeIcons>>#somethingIcon ^ self iconNamed: #something So yesâ¦ adding a selector-per-icon is not recommended because it does not scales. Esteban > > Stephan > > >

Feb. 4, 2016