March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] update of pharo by example?

by kilon alios

I had pull request phobias, I saw a doctor and I am fine now with some medication. The important thing is that you guys contribute , how you do it , its up to you. For me not having to deal with pull requests is one less thing to worry about. If I had to use them , I would . I used them once to improve the dark theme in Amber, had no issues with it. The bottom line is that more people are needed to contribute to documentation. That's the important thing, the rest is just details. On Sat, Mar 21, 2015 at 8:50 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Also, thread hijacking. :) >

March 21, 2015

TextMorph scrolling the text on edit or selection operations

by Johan Fabry

Hi all, I am assuming that I am not the only one that gets very annoyed when a TextMorph scrolls the text when typing, such that the line I am typing is always at the bottom, or scrolls the debugger when I am stepping over instructions. I looked into this (bug https://pharo.fogbugz.com/f/cases/12569/TextModel-should-not-move-scroll-wh… actually) and I found a fix. But first I want to understand why the code is as it is. Anybody have any idea why PluggableTextMorph>>setTextBasic: starts with scrollBar setValue: 0.0. ?? If I remove this line the very annoying behavior is gone, and as far as I can see there are no negative consequences on text handling (and scrolling) in general. So I am wondering why it is there at all. A slice with my fix is in the inbox if you want to play a bit with it: SLICE-Issue-12569-TextModel-should-not-move-scroll-when-accepting-text-johanfabry.1 Please have a look, this behavior has been getting on my nerves for quite some time now â¦ ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

March 21, 2015

Re: [Pharo-dev] Upgrading Fuel Data

by Max Leske

Hi Sean. Iâve added the necessary changes to Fuel so that 1.9.4 now cleanly loads (with all tests green) in Pharo 3 and Squeak 4.5. The build matrix on the CI has been updated to account for versions 1.9.3 and 1.9.4 (across all image versions) and the development build now again only builds for Pharo 4. So you can now safely do Gofer it url: 'http://smalltalkhub.com/mc/Pharo/Fuel/main'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: â1.9.4') load. in any image version prior to the latest, and in the latest of course (so in 30, 40, Squeak4.5, Squeak4.6). I hope this makes image migrations a bit easier. Please let us know if you have more suggestions (as I already said, the version problem is on our list). Cheers, Max > Begin forwarded message: > > Date: 3 Mar 2015 18:03:08 CET > From: "Sean P. DeNigris" <sean(a)clipperadams.com> > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Upgrading Fuel Data > Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > Sean P. DeNigris wrote >> To a newer user, this could be a confidence-shaking deal breaker. > > Workaround: > 1. Revert Fuel package to v. 798 i.e. just before version bump > 2. Materialize data > 3. Reload original Fuel package (currently v. 804) > > Suggestions: > 1. unless/until we have a Fuel migration tool, at minimum, any Fuel version > integrated into latest Pharo must be loadable in the previous Pharo version. > E.g. if Fuel 1.9.4 was loadable in Pharo 3.0, migration would be a bit > awkward, but doable. > 2. Maybe more guidance in the default error behavior would help e.g. put up > text suggesting to either a) temporarily downgrade Fuel to whatever version > on first materialization, or b) re-serialize in the image where the data was > serialized after upgrading Fuel > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Upgrading-Fuel-Data-tp4809243p4809265.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 21, 2015

Re: [Pharo-dev] update of pharo by example?

by Peter UhnÃ¡k

Also, thread hijacking. :)

March 21, 2015

Re: [Pharo-dev] update of pharo by example?

by Peter UhnÃ¡k

> > commits can have comments and those comments can form discussions > With git you are rarely interested in particular commits; usually when someone is proposing a feature/bugfix it composes of many commits. As a reviewer I'm not interested in every "fixed typo" commit etc, but in the whole thing, since one commit can remove a behavior and another add it, I'm interested only in the result. PRs have many other benefits * I am reviewing the code against current master * I see if there are any merge conflicts (since master could have advanced in the meantime) * If the submitter updates the feature I still have everything nicely bundled * I can have overall discussion about the proposed solution - this doesn't belong neither to commits, nor to issues since this is particular to the solution Of course it depends on your style, but for example for code reviews it is invaluable; even if both (submitter and reviewer) are contributors PR is still useful. But I am interested why you don't like pull requests; after all they are just annotated merges. Peter

March 21, 2015

Re: [Pharo-dev] update of pharo by example?

by Dmitri Zagidulin

Kilon, I'm not sure I understand - Why such resistance to pull requests? :) On Sat, Mar 21, 2015 at 2:08 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > "And then the actual repo owners/contributors have a chance to comment on > the change (with nice tools like you can comment on individual lines of > code), and ask for corrections. (And then the author of the PR can make > corrections, and they'll show up automatically in the pull request.) Then, > finally, if they approve of the contribution, the pull request is merged." > > There is a workflow of discussion for contributors , commits can have > comments and those comments can form discussions. You can also open issues > and have a discussion there pointing to specific commits. Github issues are > not just there for bugs and now with its powerful tagging system you can > use it for all sort of discussion without polluting other kinds of issues > like bugs. Wiki can also be used for roadmap , again linking to specific > commits its easy etc. Thats what I love about Github its so flexible. > > The main difference of pull requests is a way for forks to exchange code. > I am not saying you cant have a fork that closely follows the main repo and > just send pull requests but as I said in that case it would make more sense > to be a contributor directly. The whole process of accepting is not a such > a huge deal since you can always revert or even edit specific commits. > > "As a contributor to a repo, you can create a branch and a pull request > towards another branch in that very same repo, so you have access to the > same social mechanism if you want to use it." > > yeah I kinda suspected that could be possible but why not just merge and > get it done ? Again the social mechanism of pull request is not any more > social that regular contributor commits. >

March 21, 2015

Re: [Pharo-dev] update of pharo by example?

by kilon alios

"And then the actual repo owners/contributors have a chance to comment on the change (with nice tools like you can comment on individual lines of code), and ask for corrections. (And then the author of the PR can make corrections, and they'll show up automatically in the pull request.) Then, finally, if they approve of the contribution, the pull request is merged." There is a workflow of discussion for contributors , commits can have comments and those comments can form discussions. You can also open issues and have a discussion there pointing to specific commits. Github issues are not just there for bugs and now with its powerful tagging system you can use it for all sort of discussion without polluting other kinds of issues like bugs. Wiki can also be used for roadmap , again linking to specific commits its easy etc. Thats what I love about Github its so flexible. The main difference of pull requests is a way for forks to exchange code. I am not saying you cant have a fork that closely follows the main repo and just send pull requests but as I said in that case it would make more sense to be a contributor directly. The whole process of accepting is not a such a huge deal since you can always revert or even edit specific commits. "As a contributor to a repo, you can create a branch and a pull request towards another branch in that very same repo, so you have access to the same social mechanism if you want to use it." yeah I kinda suspected that could be possible but why not just merge and get it done ? Again the social mechanism of pull request is not any more social that regular contributor commits.

March 21, 2015

Re: [Pharo-dev] update of pharo by example?

by Thierry Goubier

Le 21/03/2015 17:56, Dmitri Zagidulin a Ã©crit : > On Sat, Mar 21, 2015 at 4:00 AM, kilon alios <kilon.alios(a)gmail.com > <mailto:kilon.alios@gmail.com>> wrote: > > Pull requests make more sense when you create forks and make your > own versions that go to a diffirent direction than the original > repo. When all you want is to contribute then becoming a contributor > makes more sense because its more straightforward for you and the > original authors. > > > You may be slightly misinterpreting the purpose of pull requests. > > They are not primarily for making your own versions that go in a > different direction (although they can help with that). > > They're a social / workflow mechanism, for reviewing and accepting > contributions. PRs are a way to publicly say "I would like to contribute > the following change to your repo". And then the actual repo > owners/contributors have a chance to comment on the change (with nice > tools like you can comment on individual lines of code), and ask for > corrections. (And then the author of the PR can make corrections, and > they'll show up automatically in the pull request.) Then, finally, if > they approve of the contribution, the pull request is merged. > > If you're a contributor with write access to the original repo, there > isn't a straightforward mechanism to do all of those steps. You can make > commits, but there isn't the same workflow of discussing and accepting. As a contributor to a repo, you can create a branch and a pull request towards another branch in that very same repo, so you have access to the same social mechanism if you want to use it. But, as you suggest, as a contributor you can shortcut it and commit directly. Regards, Thierry

March 21, 2015

Re: [Pharo-dev] update of pharo by example?

by Dmitri Zagidulin

On Sat, Mar 21, 2015 at 4:00 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > Pull requests make more sense when you create forks and make your own > versions that go to a diffirent direction than the original repo. When all > you want is to contribute then becoming a contributor makes more sense > because its more straightforward for you and the original authors. > You may be slightly misinterpreting the purpose of pull requests. They are not primarily for making your own versions that go in a different direction (although they can help with that). They're a social / workflow mechanism, for reviewing and accepting contributions. PRs are a way to publicly say "I would like to contribute the following change to your repo". And then the actual repo owners/contributors have a chance to comment on the change (with nice tools like you can comment on individual lines of code), and ask for corrections. (And then the author of the PR can make corrections, and they'll show up automatically in the pull request.) Then, finally, if they approve of the contribution, the pull request is merged. If you're a contributor with write access to the original repo, there isn't a straightforward mechanism to do all of those steps. You can make commits, but there isn't the same workflow of discussing and accepting.

March 21, 2015

Re: [Pharo-dev] Validation failur ZnImageExampleDelegateTests>>#testDefaultImage

by Sven Van Caekenberghe

> On 20 Mar 2015, at 21:02, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Is it possible to see the result of the failing test I can't find it ;-) I made the image used in #testUpload [ http://zn.stfx.eu/zn/Hot-Air-Balloon.gif ] smaller (it is downloaded during the test). Doing real, live networking during the tests sometimes results in failures, there is no way around that. > 2015-03-05 10:40 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > All Zn tests that run local servers work like that, using a random port from a range of 32. > > With fixed ports, we would get many more conflicts because tests and/or CI jobs are running concurrently on slaves. > > We could increase the range. > > We could pass some small unique ID to each image and use that to compute a unique port. > > Testing if a port is available is a total mess because the different socket plugins behave slightly different. > > Maybe starting servers and letting the OS give out a next available port could work, I should try that. > > In any case, unless this is a persistent problem I would not do it now. > > > On 05 Mar 2015, at 10:29, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > Anyone has an idea why this test fails so often? > > > > In > > ZnImageExampleDelegateTests>>withServerDo: block > > we use > > ZnServer on: 1700 + 32 atRandom. > > > > I don't know if this is related to the validation failure, but > > the randomly generated portnumber makes it hard get reliable results. > > > > > > > > nicolai > >

March 21, 2015