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

Re: [Pharo-dev] [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC

by Tim Felgentreff

Hi Laura, we will update the README to carify this, but yes, the Github workflow of forking and submitting pull requests should be preferred. The CI will test all changes, we can discuss on the pull requests and so on. People who continue to contribute will eventually be promoted to core contributors so they can work on the main repository, but the nice thing is that the workflow on Github with forks isn't actually very different either :) cheers, Tim On 16 June 2016 at 19:37, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Laura, Hi Tim, > > On Thu, Jun 16, 2016 at 10:09 AM, Laura Perez Cerrato > <lauraperezcerrato(a)gmail.com> wrote: >> >> >> Hi everyone, >> >> First of all, thanks a lot! >> >> Meaning to ask the same question as Serge, what's the preferred way of >> collaborating for anyone who's not a contributor? forking and then >> submitting a pull request? > > > thats on you, Tim, and I to update the README.md with a description of the > contributor and change staging process. I'm going to be checking out the > repository for the first time in a few minutes. I guess we can bat aroun > drafts between us using git itself, but perhaps email would be more sensible > ;-) > > >> >> >> Cheers! >> >> -Laura Perez Cerrato >> >> On 16 June 2016 at 06:10, Serge Stinckwich <serge.stinckwich(a)gmail.com> >> wrote: >>> >>> >>> On Thu, Jun 16, 2016 at 9:24 AM, Tim Felgentreff >>> <timfelgentreff(a)gmail.com> wrote: >>> > Hi all, >>> >>> Very impressive work, Tim&Fabio ! The power of full-automation ! >>> >>> > as of 7:30 UTC the entire history of the SVN up to SVN revision 3745 >>> > was >>> > migrated to GitHub. Automatic builds are running >>> > (https://ci.appveyor.com/project/timfel/vm/branch/Cog, >>> > https://travis-ci.org/OpenSmalltalk/vm) and binary artifacts are >>> > uploaded >>> > (https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files) >>> >>> About uploading binary artifacts, this is something I asked and this >>> nice that Fabio >>> make it work :-) >>> >>> Apparently there is some problems with some artifacts that have a >>> double .zip extension. >>> >>> > Right now we have enabled all platform, object memory and bytecode set >>> > combinations that I found build scripts for - most work, but OS X >>> > 64-bit >>> > Sista is failing right now (32-bit works). At some point we'll have to >>> > decide which combinations to put into the CI config as "allowed >>> > failures" to >>> > get a green badge :) >>> > >>> > Another thing for those not familiar with Git: Right now the entire >>> > repository is 360MB, including all history. Most of that is old images >>> > that >>> > were at one point committed to SVN and that have been pulled into the >>> > repository. We could clean those out (removing them from the history) >>> > to >>> > make the repository smaller, but I felt ~400MB is still ok (albeit >>> > technically over the Github quota. We'll see of they complain). I would >>> > like >>> > to ask everyone to stop committing large binary files into the >>> > repository, >>> > however. Git is simply not very suited to dealing with binaries. If >>> > there is >>> > a need for that, Github has support for git-lfs, which offers 1GB of >>> > free >>> > storage with a 1GB bandwith limit per month. If we need more, we can >>> > look at >>> > the different billing levels. >>> > >>> > If you're familiar with Git, the only new thing to watch out for is the >>> > updateSCSSVersions script as described in the README. It's not relevant >>> > for >>> > the CI, but your own binaries will only show correct versions if this >>> > script >>> > runs at appropriate times. >>> > >>> > If you are not familiar with Git and don't care, there are scripts for >>> > committing that should take care of everything as described in the >>> > README. >>> > Again, let us know if anything doesn't work. The only difference vs SVN >>> > to >>> > watch out for for you will be that the old scripts/svnci would commit >>> > your >>> > changes to the server, whereas the scripts/gitci script only commits >>> > them >>> > locally. You'll have to run `git pull` and `git push` to get them up to >>> > the >>> > server. >>> > >>> > If you have any questions regarding the repository setup please don't >>> > hesitate to ask. You shouldn't be able to break anything, since we've >>> > disabled force pushes to both master and Cog (and thus any chance of >>> > destroying history). >>> >>> What is favorite way of contributing for people outside the vm team ? >>> pull-requests ? >>> >>> Regards, >>> -- >>> Serge Stinckwich >>> UCBN & UMI UMMISCO 209 (IRD/UPMC) >>> Every DSL ends up being Smalltalk >>> http://www.doesnotunderstand.org/ >> >> >> > > > > -- > _,,,^..^,,,_ > best, Eliot

June 17, 2016

Re: [Pharo-dev] changes in latest Athens configuration

by Nicolai Hess

2016-06-17 9:04 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 10 Jun 2016, at 21:45, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-10 19:13 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > >> Sorry, I don't get what you mean with this: "Why do we merge compositing >> modes with "paint options"?" >> >> I just renamed paintMode -> paintOptions and moved setAA: (paint >> antialias) from canvas to paintOptions. >> >> Changing antialias mode of drawing operation is as common as changing >> composition operator. >> > > Ok, I wasn't sure if the aa-option is just an option for the whole rending > and composition mode only for the current drawing operation. > > >> Because there are two different antialiases (paint and font) it makes >> sense to have a concrete distinction between them, therefore moved paint >> antialias from canvas to paintOptions. >> >> Does it now make sense for you? >> If not, it can be reverted, anyway I don't need it anymore. >> > ? If you don't need it anymore, why is it now in the new > ConfigurationOfAthens for pharo 6.0 > > > Because these âexternal packages without maintainersâ do not work. > (the commit was in the repo and was taken into account for the new config). > The latest configuration is not yet integrated (issue validation error for 18445 ConfigurationOfAthens is not in sync with current Pharo packages) <https://pharo.fogbugz.com/f/cases/18445/ConfigurationOfAthens-is-not-in-syn…> > > We should revert the change. can you add an issue? > > Marcus > >

June 17, 2016

Re: [Pharo-dev] changes in latest Athens configuration

by Marcus Denker

> On 10 Jun 2016, at 21:45, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-06-10 19:13 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>>: > Sorry, I don't get what you mean with this: "Why do we merge compositing modes with "paint options"?" > > I just renamed paintMode -> paintOptions and moved setAA: (paint antialias) from canvas to paintOptions. > > Changing antialias mode of drawing operation is as common as changing composition operator. > > > Ok, I wasn't sure if the aa-option is just an option for the whole rending and composition mode only for the current drawing operation. > > Because there are two different antialiases (paint and font) it makes sense to have a concrete distinction between them, therefore moved paint antialias from canvas to paintOptions. > > Does it now make sense for you? > If not, it can be reverted, anyway I don't need it anymore. > > ? If you don't need it anymore, why is it now in the new ConfigurationOfAthens for pharo 6.0 > Because these âexternal packages without maintainersâ do not work. (the commit was in the repo and was taken into account for the new config). We should revert the change. can you add an issue? Marcus

June 17, 2016

Re: [Pharo-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

by Eliot Miranda

> On Jun 16, 2016, at 3:32 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > >> On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Alistair, >> >> On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >>> >>>> On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: >>>> Hi All, >>>> >>>> so after fixing "git remote get-url origin" to fail over to "git remote >>>> show origin | filter and munge" the culture shock of "git commit -a" >>>> (git >>>> commit does nothing ?!?!?) >>> >>> "git commit" will commit anything that has been "git add"ed to the >>> index. -a is a convenience to automatically stage files that have been >>> modified. >> >> >> What I don't understand is how, or indeed why, one stages modified files. I >> get that adding files requires informing git. But why doesn't "git commit" >> commit modified files by default? Why do I have to use git commit -a to >> include modified files? > > Because you can choose what files will be part of the commit > (cherry-picking changes). Ok. My objection is primarily linguistic. For me "add" means include a previously uncontrolled file to the set under control, /not/ stage this for commit. I'm happy with the concept of staging; Bert implement Ted it in Monticello in being able to select changes to ignore (but note the improvement; the default is to commit all changes; the exception is to exclude; git has this bass-ackwards). But one should call a spade a spade and have a command called eg stage, not misuse add. My problems aren't with hits concepts; they're to do with gits willfully perverse nomenclature. Add ferchrissakes. It's absurd. At least I'll get used to it now ;-) > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

June 17, 2016

Re: [Pharo-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

by Ben Coman

On Fri, Jun 17, 2016 at 10:47 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, Jun 17, 2016 at 6:46 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> >> On 17 June 2016 at 00:08, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> What I don't understand is how, or indeed why, one stages modified files. >>> I get that adding files requires informing git. But why doesn't "git >>> commit" commit modified files by default? Why do I have to use git commit >>> -a to include modified files? >> >> >> The mindset with git is that your working copy is a sort of experimentation >> area where you can have a crazy scientist attitude. When you commit, >> however, you switch hats and become the thorough developer that cares about >> your future self, and therefore has done all changes in a perfect didactic >> sequence so that you can understand what the hell your future-past-self was >> doing. >> >> If your crazy-scientist-self is already auto-censored into producing limpid >> incremental patches, then he can use git aliases for his preferred workflow >> (for instance I have git ci, git co, git st configured to mimic their svn >> counterparts; git staged shows a diff of what's to be committed next, etc) > > While creating svn like aliases and using "commit -a" may initially > aid transition to git from svn, consider that this is a bit like a C > programmer migrating to C++ to earn OO, versus learning OO by using > Smalltalk. The hybrid nature of the C++ impedes them changing their > *mindset* to use OO the full power of OO. In some respects it is > better to make the effort up front to change mindset, but of course > that needs to balanced against productivity today. > > cheers -ben > > P.S. Just to complete my other reply... >> Personally I like the staging area as a final check to observe what I'm *really* committing, > > Instead of "commit -a" which atomically does... git add -u ; git commit > I like to separately use something like... > git add -u ; git diff --staged ; git commit but actually there is a subtle difference if you are in a subdirectory when you issue the commands... http://stackoverflow.com/questions/3541647/git-add-vs-git-commit-a

June 17, 2016

Re: [Pharo-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

by Ben Coman

On Fri, Jun 17, 2016 at 6:46 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > On 17 June 2016 at 00:08, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> What I don't understand is how, or indeed why, one stages modified files. >> I get that adding files requires informing git. But why doesn't "git >> commit" commit modified files by default? Why do I have to use git commit >> -a to include modified files? > > > The mindset with git is that your working copy is a sort of experimentation > area where you can have a crazy scientist attitude. When you commit, > however, you switch hats and become the thorough developer that cares about > your future self, and therefore has done all changes in a perfect didactic > sequence so that you can understand what the hell your future-past-self was > doing. > > If your crazy-scientist-self is already auto-censored into producing limpid > incremental patches, then he can use git aliases for his preferred workflow > (for instance I have git ci, git co, git st configured to mimic their svn > counterparts; git staged shows a diff of what's to be committed next, etc) While creating svn like aliases and using "commit -a" may initially aid transition to git from svn, consider that this is a bit like a C programmer migrating to C++ to earn OO, versus learning OO by using Smalltalk. The hybrid nature of the C++ impedes them changing their *mindset* to use OO the full power of OO. In some respects it is better to make the effort up front to change mindset, but of course that needs to balanced against productivity today. cheers -ben P.S. Just to complete my other reply... > Personally I like the staging area as a final check to observe what I'm *really* committing, Instead of "commit -a" which atomically does... git add -u ; git commit I like to separately use something like... git add -u ; git diff --staged ; git commit cheers -ben

June 17, 2016

Re: [Pharo-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

by Ben Coman

On Fri, Jun 17, 2016 at 6:08 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alistair, > > On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: >> >> On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: >> > Hi All, >> > >> > so after fixing "git remote get-url origin" to fail over to "git remote >> > show origin | filter and munge" the culture shock of "git commit -a" >> > (git >> > commit does nothing ?!?!?) What do you mean "nothing" ? If you do "git status" before and after you should see some difference. If you mean "why didn't ii push to the server", here [1] is a good diagram, and the next page also is good, plus this one on branching mindset change [2] and nice introduction to undoing things [3] (for your local repo only.) >> >> "git commit" will commit anything that has been "git add"ed to the >> index. -a is a convenience to automatically stage files that have been >> modified. > > > What I don't understand is how, or indeed why, one stages modified files. I > get that adding files requires informing git. But why doesn't "git commit" > commit modified files by default? Why do I have to use git commit -a to > include modified files? Staging is a significant difference of git to svn, so a few opinions on the benefit of staging [4] [5] [6] [7] is useful. Personally I like the staging area as a final check to observe what I'm *really* committing, particularly when my working area has become a bit messy. Now as described in one of the links, "git commit -a" is a way ignore the staging area so git acts more like svn, but here are some insightful stories from people that were initially annoyed by the staging area but later found it useful [8] [9]. And btw, a quickstart git/svn cheat sheet [10]. cheers -ben [1] https://www.git-tower.com/learn/git/ebook/en/command-line/appendix/from-sub… [2] https://www.git-tower.com/learn/git/ebook/en/command-line/branching-merging… [3] https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/u… [4] http://stackoverflow.com/questions/4878358/why-would-i-want-stage-before-co… [5] http://programmers.stackexchange.com/questions/69178/what-is-the-benefit-of… [6] http://stackoverflow.com/questions/4878358/why-would-i-want-stage-before-co… [7] http://gitolite.com/uses-of-index.html [8] http://blog.osteele.com/posts/2008/05/my-git-workflow/ [9] http://2ndscale.com/rtomayko/2008/the-thing-about-git [10] https://www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/

June 17, 2016

Re: [Pharo-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

by Damien Pollet

On 17 June 2016 at 00:08, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > What I don't understand is how, or indeed why, one stages modified files. > I get that adding files requires informing git. But why doesn't "git > commit" commit modified files by default? Why do I have to use git commit > -a to include modified files? > The mindset with git is that your working copy is a sort of experimentation area where you can have a crazy scientist attitude. When you commit, however, you switch hats and become the thorough developer that cares about your future self, and therefore has done all changes in a perfect didactic sequence so that you can understand what the hell your future-past-self was doing. If your crazy-scientist-self is already auto-censored into producing limpid incremental patches, then he can use git aliases for his preferred workflow (for instance I have git ci, git co, git st configured to mimic their svn counterparts; git staged shows a diff of what's to be committed next, etc) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

June 16, 2016

Re: [Pharo-dev] Unambiguously differentiating official and local builds [Was [Vm-dev] Moving the Cog subversion repository to githup at 2016-6-16 7am UTC]

by Serge Stinckwich

On Thu, Jun 16, 2016 at 11:08 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alistair, > > On Thu, Jun 16, 2016 at 1:43 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: >> >> On Thu, Jun 16, 2016 at 01:07:23PM -0700, Eliot Miranda wrote: >> > Hi All, >> > >> > so after fixing "git remote get-url origin" to fail over to "git remote >> > show origin | filter and munge" the culture shock of "git commit -a" >> > (git >> > commit does nothing ?!?!?) >> >> "git commit" will commit anything that has been "git add"ed to the >> index. -a is a convenience to automatically stage files that have been >> modified. > > > What I don't understand is how, or indeed why, one stages modified files. I > get that adding files requires informing git. But why doesn't "git commit" > commit modified files by default? Why do I have to use git commit -a to > include modified files? Because you can choose what files will be part of the commit (cherry-picking changes). -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

June 16, 2016

Re: [Pharo-dev] GT-Spotter dive in shortcut

by Nicolai Hess

2016-06-16 22:45 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > I think we are mixing the topics a bit. The #meta discussion is not > specific to Spotter actions. > On windows, it is. Because on windows #meta is mapped to #ctrl, and you can use ctrl+left/right for moving by "words". This works in a browser, an editor, pharos text components but *not* in spotter because spotter redefines this keystrokes for dive in /out. Currently, both ctrl+left/right and alt+left/right (and shift for selection) are working in rubric for moving by "word". But only because the (old) shortcut (cmd/shiftcmd) action dispatcher explicitly allows both. If we want to remove this and use the KMDispatcher framework only, we *need* to define only one mapping, otherwise you won't be able to use dive in/out in spotter. (Or you could modify spotter to register(overwrite) the mapping on the textfield instead of the spotter morph). > The idea was to offer a uniform support of keybindings in Pharo, in > general. exactly, and using ctrl+left/right uniformly in editor and external tools would be great. > Then Guille etal added #meta to have a predictable mapping. Yes, and to make this work, we have to remove the old keymapping implementation (cmd/shiftcmd action map) and use the KMDispatcher registration. But I can only continue with this if we have a decision what to use, (windows/linux: either ctrl+arrow or alt+arrow, mac: whatever is used on a mac for text navigation) All #cmd places were changed to #meta, and since then we should not use > explicitly #cmd anymore, except when we know we are on Mac. For a portable > modifier, we should only use #meta. > > At this point, both Rubric and Spotter use #meta. #meta maps on: > - Mac: Command > - Win: Control > - Linus: Control > > This means that #alt is now a portable modifier that will not conflict > with #meta, so we can now think of using that one in combination with #meta. > You can not use #alt modifier on windows. A shortcut definition like $g alt is never recognized. You have to define it $g command to make it work with as "alt+g"-keycombination (on windows). > For text navigation, the situation is a bit complicated. On Win/Linux, > Ctrl+Right/Left moves the cursor between words. On Mac, Cmd+Right/Left > moves the cursor at the end/beginning of line. So, using #meta for text > navigation between words is not entirely accurate. We should use #ctrl > instead. > > This would anyway mean that it would be an option to use #alt for Spotter > now. But, if we are at it, would anyone be interested in working on > revisiting the overall keybindings in Pharo? > > Cheers, > Doru > > > > > On Jun 16, 2016, at 10:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > 2016-06-07 16:12 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > We can, but I remember there were some discussions and it was decided to > use meta everywhere. > > > > Cheers, > > Andrei > > > > > > If we don't change this, I'll use cmd+left cmd+right in rubric, but this > is bad, because all other navigate/select+navigate shortcuts would use meta > as shortcut modifier. > > > > What are the arguments for using meta for dive-in/out shortcuts ? > > > > > > > > On Tue, Jun 7, 2016 at 3:49 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > 2016-06-07 15:08 GMT+02:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > > During Pharo 5 most shortcuts from tools were changed to use "meta" > instead of cmd. > > > > Cheers, > > Andrei > > > > Can we change this for spotter ? cmd instead of meta > > > > ctrl left/right is often used for text components to move to > next/previous word. > > > > > > > > On Tue, Jun 7, 2016 at 2:18 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > 2016-06-07 13:57 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > Am 07.06.2016 1:56 nachm. schrieb "Henrik Nergaard" < > henrik.nergaard(a)uia.no>: > > > > > > IIRC the shortcut is not changed, it still is meta+right(+shift). Only > the tooltip was changed to display the system specific key instead of âcmdâ > so for Windows/Linux this would be âctrlâ. > > > > > > No, it changed > > > > In #40624, for example, it was cmd (alt-key on windows ) right/shift > right > > > > > > > > > > > > > > > > Best regards, > > > > > > Henrik > > > > > > > > > > > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf > Of Nicolai Hess > > > Sent: Tuesday, June 7, 2016 12:56 PM > > > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Subject: [Pharo-dev] GT-Spotter dive in shortcut > > > > > > > > > > > > Why did the shortcut for dive-in element/category changed from > > > > > > cmd+right > > > > > > cmd+shift+right > > > > > > to > > > > > > ctrl+right > > > ctrl+shift+right > > > > > > I know there were some discussions about this and that the behavior > changed some > > > > > > time ago, but I don't know the rational behind this. > > > > > > thanks > > > > > > nicolai > > > > > > > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > >

June 16, 2016