January 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Blame support P7

by David T. Lewis

On Sat, Jan 13, 2018 at 04:49:07PM +0100, Sven Van Caekenberghe wrote: > > > > On 13 Jan 2018, at 15:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Sven, > > > >> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >> > >>> On 13 Jan 2018, at 05:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >>> > >>> Isn't it important to preserve the ability to exchange code between Pharo, Squeak and Cuis? Don't you care that the VM development is directly affected by this? Is the VM and plugin support not important to Pharo? > >> > >> Eliot, > >> > >> Not trying to minimise your contributions (we all love the VM), and I know that you favour collaboration, but > >> > >> (1) what non-trivial code is actively maintained from a single code base between Pharo, Squeak and Cuis ? > > > > Alien > > Hmm, not that active. And it requires Pharo/Cuis to use an 'older' loading mechanism (from their perspective evolving to git SCM). > > Other than that, a very short list. You know just as well as that it is close to impossible to do this (Seaside and FUEL are the only real counter examples, and even there it is a lot of work). > Indeed, Seaside and FUEL are good examples. My own experience is with OSProcess/CommandShell, which I develop in Squeak, version control in Monticello, and intermittently try to maintain for Pharo and Cuis. As you say, this can be difficult to do. Multiple version control approaches do not make the job any easier, and I can assure you that it does not make it any more enjoyable. I am probably not a good example, because I am just one person, not a development team. But for what it's worth, that is my experience. Dave

Jan. 14, 2018

Re: [Pharo-dev] Blame support P7

by David T. Lewis

On Sun, Jan 14, 2018 at 12:52:52AM +0800, Ben Coman wrote: > > @Juan, IIUC Cuis already primarily uses git for Smalltalk source code management. > How is this currently done and would you partake in a Smalltalk > implementation of git? > You will find Juan's explanation of Git and GitHub for Cuis code management at https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentat… The introduction to that explanation is worth quoting here: > Cuis includes tools and procedures for managing Smalltalk code. Central > to this is the management of Packages and Package Files (.pck). But Cuis > doesn't do version control. Instead, we suggest using external VCS tools. > In particular, we're using GitHub, and the first project we're hosting > there is StyledTextEditor. > > The guiding principle is to not duplicate concepts and behavior. As we're > using an external tool (Git) for version control, then we use it as it > meant to be used. Most people use Git for version control and a file based > IDE such as Eclipse for development. Such IDEs don't do version control > themselves. It is done by Git. Do the same: do not include package version > control in Cuis. This is a departure from the Monticello /Git integration > (smallsource and MonticelloFileTree) by Otto Behrens, Dale Henrichs, etc. Dave

Jan. 14, 2018

Re: [Pharo-dev] Blame support P7

by Nicolas Cellier

There is obviously some kind of resentment and tension unrelated to this thread. If the result is that we can't dicuss possible solutions, then it's bad, because this is an important point. What happens if two concurrent commits modify the same method but not the same lines? Is it a conflict like in MC? If yes, then there is nothing stopping the last author/timestamp metadata to be included in source files (either directly or in a sister file). The problem we had previously with metadata was that it did include history which necessarily conflicts... (Or not, there was a viable specific merge developped for that case, may I remind https://github.com/ThierryGoubier/GitFileTree-MergeDriver) Also the format was not adequate initially (single line in the eyes of git). Author and timestamp are somehow redundant with git own metadata... Or not if there are exchange with other flavours an other backends. The very first exchange is the one way conversion to iceberg which magically erase all the metadata. Please note that these data are not temporary lost but definitely, so it's indeed a sacrifice. Then if I pick a method verbatim from Squeak to Pharo or Pharo to Squeak, that doesn't make me an author. If I wish to maintain cross compatibility for a library that means exchanging too. Minimizing the existence of such libraries or the will of maintainers is like counting a whole part of this community for nothing. If I speculate on the intentions, which is a bit dangerous in such explosive atmosphere, what are the plans for restoring the most elementary features of a VCS that are authorship and history? Use git data exclusively? 2018-01-13 17:52 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > On 13 January 2018 at 20:12, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > >> > >> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > >>> > >>> Git support turns out to be much more work than we hoped and expected. > Too > >>> many library updates needed, support for different workflows and > platforms, > >>> switch to file per class. The Iceberg channel on Discord is one of the > >>> busiest channels. > >> > >> You don't say? One of ClÃ©ment's themes in recent talks on VM > performance is > >> that we, as a very small team, are able to develop such a sophisticated > >> optimizer because we use Smalltalk. We are hugely productive in the vm > >> simulator. People using Smalltalk, including the Pharo, Squeak and Cuis > >> dialects that constitute our community, report the same in many > different > >> domains, notably Bloc, GT Toolkit and Rossal. > >> > >> Then why on /earth/ would one stop using Smalltalk in /the most central > >> part/ of the collaborative programming process, version control? This > is a > >> huge blunder. Now a major part of the Pharo community's efforts goes > into > >> an external component, upon which Pharo is entirely dependent, and > slowly > >> but surely it is cutting itself off from its sibling communities. > Iceberg > >> is well named. People rearranged the chairs on deck while the Titanic > sank. > > > > Can we agree that a class/method/â¦ stops being smalltalk after it has > been > > serialized to text? > > I sure Eliot referred to the external C library of libgit2 > regarding stepping outside of the Smalltalk environment. > Its the root source of the segfaults that is killing the reliability. > > > If you can agree to this I donât know what you are > > talking about. We exchange the to-text-serializer monticello-backend with > > git-backend. The rest (the important part) stays nearly the same. The > > exchange is necessary because the possibilities of collaboration are > limited > > when using monticello only. So what would be the alternative? > > The alternative would be a Smalltalk implementation of git. > This would surely reduce segfaults and make debugging easier with a > wider pool of contributors. > The downside would be tracking the evolution of git. Perhaps when > libgit2 was selected the balance > was foreseen in its favour. However with current experience perhaps > this balance is worth review. > > For POC, here are some other language native implementations of git... > http://www.eclipse.org/jgit/ > https://github.com/jelmer/dulwich > https://github.com/mirage/ocaml-git > https://github.com/danlucraft/git.js > https://github.com/henon/GitSharp > > THIS ARTICLE is really informative... > http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ > Can anyone here familiar with Haskell help with converting those code > examples to Smalltalk? > > > @Eliot, Given that Pharo is likely to continue down the git path, how > interested do you think the Squeak community > would be in a Smalltalk implementation of git to facilitate future > collaboration. > Maybe the question could be raised there separately? > > @Juan, IIUC Cuis already primarily uses git for Smalltalk source code > management. > How is this currently done and would you partake in a Smalltalk > implementation of git? > > > > There are even a lot of people that donât like git (including me). But I > > like the collaboration model because that can do what no smalltalk tool > can > > do to my knowledge. > > Simply we either stay the same; Or we move. Moving does risk that a > wrong path is started, > or we go a long way round, but even on a non-optimal paths much can be > learnt. > Pharo zen is "Learning from mistakes." and while I don't believe > libgit2 was a mistake > since it allowed Iceberg development to start at a higher level, > perhaps replacing it with a native Smalltalk implementation is worth a > trial. > Some subparts of this might make a good GSoC project (?) > > cheers -ben > > > P.S. No-one has mentioned the "content addressable" nature of git > which I believe > is the *real* paradigm shift in VCS that we should pursue. With a > CompiledMethod referencing > a hash of its method-source rather than a location in a particular > file on a filesystem, > opens the possibility of a dozen different providers for locating that > method-source that > are all equivalent and substitutable with one another for maintaining > compatibility between Smalltalk dialects. > The hash could reference a "git object" of that hash, or an entity on > IPFS (https://ipfs.io) > or http://my.simpleServer.com/methodhash. > >

Jan. 13, 2018

Spec dynamic layout without dynamic widgets

by HernÃ¡n Morales Durand

Hi guys, A comment from building Spec layouts for widgets (Pharo 6 but maybe applicable to Pharo >= 7): I have built a Spec widget which could have two layouts: #buttonsOnTopSpec and #buttonsOnBottomSpec : SpcLabeledActionsList new openWithSpec: #buttonsOnTopSpec; yourself. SpcLabeledActionsList new openWithSpec: #buttonsOnBottomSpec; yourself. Now if you would have to set such list as a widget in #initializeWidgets, the building process follows its path to #private_buildWithSpec which hardcodes the spec layout to the #defaultSpecSelector (the one containing <spec: #default> pragma). The problem subclassing from DynamicComposableModel / Presenter is that is trying to solve two problems at once: 1) Dynamic adding/removing widgets 2) Dynamic configuration of layout In this case I just need the 2), and I would have to remove inst. vars and accessors in ~20 classes because the dynamic widgets dictionary now stores all widgets, or interject a weirdo between ComposableModel/Presenter and DynamicComposableModel/Presenter. What would you do? Cheers, HernÃ¡n

Jan. 13, 2018

Re: [Pharo-dev] cannot write to the changes file

by Ben Coman

On 13 January 2018 at 19:37, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > Le 13/01/2018 Ã 12:36, Cyril Ferlicot D. a Ã©crit : >> >> Hi, >> >> For my part it inform that the source file cannot be written at launch >> but in the end it is written. >> >> This problem comes from a refactoring in the location system I think. >> > > Pavel located the problem with the merge of this PR: : > https://github.com/pharo-project/pharo/pull/553 Great! That was quick work (thanks Pavel.) Do you have an issue for me to follow, or should I create it? cheers -ben

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Ben Coman

On 13 January 2018 at 20:12, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 13.01.2018 um 12:39 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> On Jan 13, 2018, at 2:08 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> Git support turns out to be much more work than we hoped and expected. Too >>> many library updates needed, support for different workflows and platforms, >>> switch to file per class. The Iceberg channel on Discord is one of the >>> busiest channels. >> >> You don't say? One of ClÃ©ment's themes in recent talks on VM performance is >> that we, as a very small team, are able to develop such a sophisticated >> optimizer because we use Smalltalk. We are hugely productive in the vm >> simulator. People using Smalltalk, including the Pharo, Squeak and Cuis >> dialects that constitute our community, report the same in many different >> domains, notably Bloc, GT Toolkit and Rossal. >> >> Then why on /earth/ would one stop using Smalltalk in /the most central >> part/ of the collaborative programming process, version control? This is a >> huge blunder. Now a major part of the Pharo community's efforts goes into >> an external component, upon which Pharo is entirely dependent, and slowly >> but surely it is cutting itself off from its sibling communities. Iceberg >> is well named. People rearranged the chairs on deck while the Titanic sank. > > Can we agree that a class/method/â¦ stops being smalltalk after it has been > serialized to text? I sure Eliot referred to the external C library of libgit2 regarding stepping outside of the Smalltalk environment. Its the root source of the segfaults that is killing the reliability. > If you can agree to this I donât know what you are > talking about. We exchange the to-text-serializer monticello-backend with > git-backend. The rest (the important part) stays nearly the same. The > exchange is necessary because the possibilities of collaboration are limited > when using monticello only. So what would be the alternative? The alternative would be a Smalltalk implementation of git. This would surely reduce segfaults and make debugging easier with a wider pool of contributors. The downside would be tracking the evolution of git. Perhaps when libgit2 was selected the balance was foreseen in its favour. However with current experience perhaps this balance is worth review. For POC, here are some other language native implementations of git... http://www.eclipse.org/jgit/ https://github.com/jelmer/dulwich https://github.com/mirage/ocaml-git https://github.com/danlucraft/git.js https://github.com/henon/GitSharp THIS ARTICLE is really informative... http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/ Can anyone here familiar with Haskell help with converting those code examples to Smalltalk? @Eliot, Given that Pharo is likely to continue down the git path, how interested do you think the Squeak community would be in a Smalltalk implementation of git to facilitate future collaboration. Maybe the question could be raised there separately? @Juan, IIUC Cuis already primarily uses git for Smalltalk source code management. How is this currently done and would you partake in a Smalltalk implementation of git? > There are even a lot of people that donât like git (including me). But I > like the collaboration model because that can do what no smalltalk tool can > do to my knowledge. Simply we either stay the same; Or we move. Moving does risk that a wrong path is started, or we go a long way round, but even on a non-optimal paths much can be learnt. Pharo zen is "Learning from mistakes." and while I don't believe libgit2 was a mistake since it allowed Iceberg development to start at a higher level, perhaps replacing it with a native Smalltalk implementation is worth a trial. Some subparts of this might make a good GSoC project (?) cheers -ben P.S. No-one has mentioned the "content addressable" nature of git which I believe is the *real* paradigm shift in VCS that we should pursue. With a CompiledMethod referencing a hash of its method-source rather than a location in a particular file on a filesystem, opens the possibility of a dozen different providers for locating that method-source that are all equivalent and substitutable with one another for maintaining compatibility between Smalltalk dialects. The hash could reference a "git object" of that hash, or an entity on IPFS (https://ipfs.io) or http://my.simpleServer.com/methodhash.

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Ben Coman

On 13 January 2018 at 20:57, Benoit St-Jean via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Bcc: > Date: Sat, 13 Jan 2018 12:57:00 +0000 (UTC) > Subject: Re: [Pharo-dev] Blame support P7 >> So what would be the alternative? > > A centralized server (e.g. Cincom Public Repository, SqueakSource, SmalltalkHub, SqueakSource 3). After that, all you need is a detailed project/package/framework description. Google will index it. > > The whole "GitHub adventure" was started on the premise that it would give Pharo more visibility. >From what I remember of mail list discussions, the primary reason to move to github, which was reducing the need for a 24x7 operations team to support our code repository servers. http://forum.world.st/SmalltalkHub-bugs-hangs-tp4792551p4792598.html There was an argument that support effort would make the servers more reliable, but it seems both SqueakSource3 and Smalltalkhub were started in response to SqueakSource issues at some time. So ti still seems reasonable to make use of these 3rd party maintained VCS services. > > Besides, Smalltalk code on GitHub leaves a very bad impression on newcomers. I was recently told "I just gave up on Smalltalk when I saw 200+ files"... It was too late. I told the poor guy it was just the way code was *stored* on GitHub but in your dev environment, everything resides in the image... Too late : I had lost him solely based on the impression that he was entering into a code management nightmare worse than a thousand C header files! Which repo was that? Was it before/after Tonel? > In the current state of things, the whole Cuis/Pharo/Squeak world is a mess. Newcomers looking for code end up having to pick between a myriad of links to SqueakMap, catalogs, SqueakSource, SmalltalkHub, SS3, GitHub, sar files, mcz files, fileOuts, etc. > Wouldn't it be nice to have a centralized server with Cuis, Pharo, Squeak (and/or others such as VW, VAST, Dolphin) and share a common import/export format (SIXX, Smalltalk Instance eXchange in XML, would be a good start and would probably do a decent job) Yes, but please not XML. JSON like would be much nicer, where Tonel could be a good option. cheers -ben

Jan. 13, 2018

Re: [Pharo-dev] ZnClient issue: ZdcPlugin Missing

by Photon

Yes thank you I figured. See my previous post edit. Nice I go study now. Have a nice evening :) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 13, 2018

Re: [Pharo-dev] [Vm-dev] [squeak-dev] [Doodle] OpenSmalltalk VM Meeting

by Nicolas Cellier

I will not be able to attend, but i'am also interested in some kind of minutes of meeting. Nicolas Le 13 janv. 2018 15:20, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : > > Any chance that parts of this can be recorded - particularly the update on > Sista? > For me these slots start 11pm to 4am and next week I'll be on-site getting > up at 4am to head to work. > I'm happy to do any post-production work. > cheers -ben > > On 13 January 2018 at 21:27, Fabio Niephaus <lists(a)fniephaus.com> wrote: > >> Hi all, >> This is a friendly reminder that you can still sign up for the below >> until tomorrow evening. >> >> Best, >> Fabio >> >> -- >> >> On Mon, Jan 8, 2018 at 8:46 PM Fabio Niephaus <lists(a)fniephaus.com> >> wrote: >> >>> Hi all, >>> >>> When ClÃ©ment and I recently talked about the next VM release, we thought >>> it might be good to organize a meeting and invite everyone who would be >>> interested. The agenda is yet to be finalized, but I think it would be >>> great if ClÃ©ment and/or Eliot could give an update on their work on Sista. >>> And I could give an overview of what still needs to be done for the release >>> or how we plan to sign and update the release bundles. I'm sure there is a >>> lot more we can talk about. >>> >>> If you would like to attend, please indicate your availability using >>> this Doodle link by Sunday, 14th January: https://doodle.com/poll/cyei4a >>> x4sd43m522. >>> >>> Looking forward to seeing you all soon. >>> >>> Best, >>> Fabio >>> >> >> >> >> > >

Jan. 13, 2018

Re: [Pharo-dev] Blame support P7

by Eliot Miranda

> On Jan 13, 2018, at 7:49 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 13 Jan 2018, at 15:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Sven, >> >>> On Jan 13, 2018, at 6:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> >>>> On 13 Jan 2018, at 05:22, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> Isn't it important to preserve the ability to exchange code between Pharo, Squeak and Cuis? Don't you care that the VM development is directly affected by this? Is the VM and plugin support not important to Pharo? >>> >>> Eliot, >>> >>> Not trying to minimise your contributions (we all love the VM), and I know that you favour collaboration, but >>> >>> (1) what non-trivial code is actively maintained from a single code base between Pharo, Squeak and Cuis ? >> >> Alien > > Hmm, not that active. And it requires Pharo/Cuis to use an 'older' loading mechanism (from their perspective evolving to git SCM). Alien contains callbacks. As such, fundamental parts of Pharo depend on it. And your comment "use an 'older' loading mechanism" demonstrates that the git integration is not simply a back-end, but is affecting Monticello, IMO not for the better. > Other than that, a very short list. You know just as well as that it is close to impossible to do this (Seaside and FUEL are the only real counter examples, and even there it is a lot of work). I disagree. The core of refactoring (all except a small tool layer) is in common. And there are numerous compatibility packages out there, grease, but also, as in the refactoring engine, a common core with small Foo-Platform-Pharo & Foo-Platform-Squeak etc. I think to home up with an accurate picture free of our differences my opinions we would have to make a list. > >>> (2) how/where are you developing in Pharo ? I only see you contributing to Squeak, where only a handful of very experienced developers are making occasional, conservative changes to maintain their own environment. >> >> You may be using the 64-bit version of Pharo. That is my work. If you're using the FFI then I've had a part in it (callbacks being the most specific). And the new release will use the Sista bytecode set. That's me and ClÃ©ment. ClÃ©ment and others integrate stuff on my behalf. I also work closely with people in the Pharo community and get work from users of Pharo. Pharo is important to me. But this isn't about me. > > I started by saying that I know and appreciate your work. Since I did not say anything otherwise, you do not need to get defensive. I'm not being defensive. You made this personal. I wanted to state that I have made contributions to contradict your assertion that. Eye be the vm I did not. But I have nothing to feel defensive about. On the contrary I care about the collaboration between different communities above the common vm, and I care deeply; I gave skin in the game. > > "They integrate an my behalf" is exactly my point: you do something in your closed world and others can follow. How is "my world" my world, and how is it closed? >> I disagree with your description of the Squeak community. St Potsdam it is used by students. The raspberry pi scratch was in Squeak until late last year. It is not as you describe. > > It is and you know it. I'd appreciate it if you would refrain from projecting on me. I'm not in the habit of lying. It isn't. You're entitled to your opinion as I am to mine. > >>> For me, and many others the VM is a completely closed ecosystem, a black box. A know the simulator is cool, but I have never seen it. >> >> What does that have to do with this discussion? > > Because you argue about collaboration while you act in a certain way. Again, I am fine if you make certain choices, everyone does, but you cannot ask others to do what you do no do yourself. Again you presume to know about my actions. I don't presume to know about your activities. > >>> Your choice to use Squeak is a valid one that probably makes sense to you, but you must also respect the successful alternative that Pharo is. >> >> Again how does my criticisms my the git integration have anything to do with Pharo being a successful alternative? Do you think I want Pharo to fail? Do you think I would bother commenting if I wasn't interested? > > SCM and moving to git was argued about ad infinitum for years, Pharo (and others) are moving to it since a very long time. We're not there yet, but progress is good. (And yes the timestamps have to come back, the history is another issue). Starting 2018 by attacking that all that work is very cool indeed ;-) > > Stef explained factually how we still maintain enough modelling in Smalltalk. > >>> Sven >>> >>>> Stef >>>> >>>>> On Fri, Jan 12, 2018 at 1:09 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> Not having timestamps/authors in Pharo 7 due to git and missing blame support >>>>> (see [1]) has other bad side effects: >>>>> >>>>> >>>>> - it clobbers all method stamps in an MCZ package [1] if you use Monticello >>>>> which can lead easily to trouble/lamenting >>>>> >>>>> - it is not possible to fileout a changeset [2] in the ChangeSorter >>>>> >>>>> Was there any further discussion/decision for P7 on solving this >>>>> or adding blame support? >>>>> >>>>> Thx >>>>> T. >>>>> >>>>> >>>>> [1] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html >>>>> [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html >>>>> [3] https://pharo.fogbugz.com/f/cases/20951/ > >

Jan. 13, 2018