November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Stuck trying to contribute

by Torsten Bergmann

Hi Sven, if you like you can try: https://github.com/astares/pharo-contributor Easy to use: Â - clone this project Â - run download.sh to download and run latest P7 image, this will also load Â Â Â a help tutorial explaining how you can easily contribute and keep your fork up to date There is a tool inside that downloads your fork or helps you staying up to date. All is explained and if you do not care on bandwidth there is also a "clean.sh" (to cleanup) so you can start fresh again with "download.sh" afterwards. There is a also a "start.sh" (to just start the image when it should be reused). Hope this helps a little bit. Thanks T. Am 16.11.2017 um 00:21 schrieb Sven Van Caekenberghe: > >> On 15 Nov 2017, at 22:47, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >> >> >> 2017-11-15 22:27 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> Alistair, >> >> Are steps 8 & 9 needed, since the latest image should be in sync with the latest dev version, no ? >> >> 8) the latest build may not be created from the latest merged commit. This step is not necessary because Iceberg can handle such situations and moreover it can do cherry-picking during commits. However personally I use it because it reduces probability of troubles. As always, it is good to execute it only if you know what you are doing and what you want. >> >> 9) is not needed anymore >> >> BTW, Guille wrote a very nice document about your fork synchronization >> https://github.com/guillep/PharoIntegrationProcess/wiki/Keep-your-repo-in-s… > I ended up using those instructions > > $ git checkout development > $ git pull https://github.com/pharo-project/pharo.git development > $ git push https://github.com/svenvc/pharo.git development > > I guess that is exactly what the Pharo code does. > > This feels better. > > Thx! > >> -- Pavel >> >> >> Sven >> >> @Pavel, thanks as well. A lot seems possible with the API. >> >> I hope to be able to try later tonight. >> >>> On 15 Nov 2017, at 21:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Sven, >>> >>> On 15 November 2017 at 20:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> Yes, it is working for me too now, and it is actually pretty nice. >>>> >>>> I wonder though what the best way is to keep your personal fork up to date ? >>>> >>>> I managed to do it with a PR from the fork to the origin (or is it the reverse ?), like this >>>> >>>> https://github.com/svenvc/pharo/pull/1 >>>> >>>> but it felt a bit weird because obviously the diff is large and I had the impression that the CI process than had to process all this. >>>> >>>> Maybe there is a better/easier/more correct way ? >>> I only update my fork when I'm starting from a fresh image - my >>> understanding is that upgrading an image is not supported at the >>> moment. >>> >>> Set up the repository: >>> >>> cd emptydirectory >>> wget 'the latest 7.0 image' >>> git clone git@github.com:pharo-project/pharo.git pharo-core >>> cd pharo-core >>> git remote add $username git@github.com:$username/pharo.git >>> cd .. >>> >>> Once the repository has been set up, the following script: >>> >>> 1. Configures Iceberg to show system repositories >>> 2. Finds the pharo repository. >>> 3. Finds the two remotes (origin and $username, from above) >>> 4. Configures Iceberg to pull from origin and push to $username by default. >>> 5. Checks out the development branch >>> >>> and finally does what you were asking about, updating the fork from the origin >>> >>> 6. Pull from origin >>> 7. Push to fork ($username) >>> 8, Checkout the images commit >>> 9. Reloads modified packages >>> >>> >>> | location username pharoRepository origin myfork | >>> >>> location := 'pharo-core'. >>> username := 'myusername'. >>> >>> Iceberg showSystemRepositories: true. >>> pharoRepository := IceRepository registry detect: [ :each | each name >>> = 'pharo' ]. >>> pharoRepository location: location asFileReference. >>> origin := pharoRepository remotes detect: [ :each | each remoteName = >>> 'origin' ]. >>> myfork := pharoRepository remotes detect: [ :each | each remoteName = >>> username ]. >>> pharoRepository pushRemote: myfork. >>> pharoRepository pullRemote: origin. >>> pharoRepository checkoutBranch: 'development'. >>> pharoRepository backend pullFrom: origin. >>> pharoRepository push. >>> pharoRepository checkoutBranch: (SystemVersion current commitHash). >>> [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded >>> and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning >>> do: [ :warning | warning resume: true ]. >>> >>> 'Loaded pharo-core' inspect. >>> >>> >>> I always have OSSubprocess loaded, so it would actually be easy to >>> automate the cloning and configuration of the repository. I might do >>> that next week. >>> >>> Cheers, >>> Alistair >>> >>> >>> >>>>> On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>> >>>>> Just to add a positive note to this discussion: >>>>> >>>>> After cloning the pharo repository, adding my fork as a remote and >>>>> using Guille's scripts from earlier this year to configure the >>>>> repositories in image, I was able to: >>>>> >>>>> - Create new branch from Fogbugz issue... >>>>> - Make the changes >>>>> - Push the changes up to my fork (Synchronise repository) >>>>> - Create pull request... >>>>> - Make some more changes >>>>> - Push changes to my fork >>>>> >>>>> All from within the image, without any problems. >>>>> >>>>> There's still plenty that is manual and outside the image, and it >>>>> would be nice to have a GUI that guided you through the process (at >>>>> the moment you need to know what steps to do and in what order), but >>>>> we have a good solid basis for moving forward. >>>>> >>>>> Cheers, >>>>> Alistair >>>>> >>>>> >>>>> >>>>> On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>>>>> >>>>>>> Sven >>>>>>> >>>>>>> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >>>>>>> the pain for me. >>>>>> Ah, OK, found it. Thanks. >>>>>> >>>>>> Nice document BTW ;-) >>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>>>>>> >>>>>>>> If you give me precise instructions I can update the post :) >>>>>>> precise instructions is: >>>>>>> - do not use https, use ssh >>>>>>> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >>>>>>> >>>>>>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>>> I think I succeeded: >>>>>>>> >>>>>>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>>>>>>> https://github.com/pharo-project/pharo/pull/420 >>>>>>>> >>>>>>>> It does contain 4 identical commits due to my troubles earlier on. >>>>>>>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>>>>>>> >>>>>>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> hi, >>>>>>>>>> >>>>>>>>>> thing is, you should not use https authentication (and the guide should not point to it) >>>>>>>>>> Using SSH mode works out of the box. >>>>>>>>>> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>>>>>>>> Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>>>>>>>> >>>>>>>>> Thanks ! >>>>>>>>> >>>>>>>>>> Esteban >>>>>>>>>> >>>>>>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>>>>>>>>>> >>>>>>>>>>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>>>>>>>>>> >>>>>>>>>>> $ sw_vers >>>>>>>>>>> ProductName: Mac OS X >>>>>>>>>>> ProductVersion: 10.13 >>>>>>>>>>> BuildVersion: 17A405 >>>>>>>>>>> >>>>>>>>>>> $ curl get.pharo.org/70+vm | bash >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> $ ./pharo-ui Pharo.image >>>>>>>>>>> >>>>>>>>>>> I now have the following setup, which is correct I think. >>>>>>>>>>> >>>>>>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> >>>>>>>>>>> >>>>>>>>>>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>>>>>>>>>> >>>>>>>>>>> Locally, I see >>>>>>>>>>> >>>>>>>>>>> $ git status >>>>>>>>>>> On branch 20613-Improve-some-UUID-comments >>>>>>>>>>> nothing to commit, working tree clean >>>>>>>>>>> >>>>>>>>>>> with the new code already committed >>>>>>>>>>> >>>>>>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>>>>>>>>>> instance creation >>>>>>>>>>> new >>>>>>>>>>> "Create and return a new UUID" >>>>>>>>>>> >>>>>>>>>>> "self new" >>>>>>>>>>> >>>>>>>>>>> ^ (self new: 16) >>>>>>>>>>> >>>>>>>>>>> What did I do wrong ? How do I proceed ? >>>>>>>>>>> >>>>>>>>>>> Sven >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Guille Polito >>>>>>>> Research Engineer >>>>>>>> >>>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>>>> CRIStAL - UMR 9189 >>>>>>>> French National Center for Scientific Research - http://www.cnrs.fr >>>>>>>> >>>>>>>> Web: http://guillep.github.io >>>>>>>> Phone: +33 06 52 70 66 13 >> >> >

Nov. 16, 2017

Zero-conf glitch with latest contribution

by Torsten Bergmann

Hi Guille, the last contribution from your side (merged by Estebann this week) for the zero-conf scripts have a glitch. When running the zeroconf for Pharo 7 I receive an "https://github.com/pharo-project/pharo-zeroconf no such file or directory error" error on the bash command line. The reason is simple: in https://github.com/pharo-project/pharo-zeroconf/commit/bdd756d7016b5fdfbef2… the last line in #generateHtmlHeader does not have a # sign for commenting the URL: self << '#<html><head><!--'; cr; << '#<html><head><!--'; cr; << '# The above line makes a fake HTML document out of this bash script'; cr. + << '# The line above makes a fake HTML document out of this bash script'; cr; cr; << '#This zero conf script was generated from the sources found in:'; cr; tab; << 'https://github.com/pharo-project/pharo-zeroconf'; cr. Can you please fix that? Thanks T.

Nov. 16, 2017

[Pharo 7.0-dev] Build #297: 20696-enable-bootstrapping-from-outside-the-repository

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #297 was: SUCCESS. The Pull Request #485 was integrated: "20696-enable-bootstrapping-from-outside-the-repository" Pull request url: https://github.com/pharo-project/pharo/pull/485 Issue Url: https://pharo.fogbugz.com/f/cases/20696 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 16, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Henrik Sperre Johansen

Thomas Dupriez wrote > While working on writing a test, I discovered that just using > stepThrough instead of stepOver may not be the definitive solution. > > # Example1: When using the `value` message directly (instead of calling > a method that does that as in my previous example), the RunToHere moves > the debugSession to the `value` message and not the inside of the block. It's a good compromise though, anything more involved, and you quickly run into problems if the point you want to "run to", is in a branch not taken. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 16, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Guillermo Polito

Thanks Thomas :) I'll take a look! On Wed, Nov 15, 2017 at 6:29 PM, Thomas Dupriez < thomas.dupriez(a)ens-paris-saclay.fr> wrote: > Here they are: > > https://github.com/dupriezt/Pharo-RunToSelectionDebuggerFeature > > Le 15/11/2017 Ã 10:47, Guillermo Polito a Ã©crit : > > Thomas, can you try writing some real test cases in SUnit? > > I don't care if they are originally red (they will be because it is not > working). > > The idea is that we capture all these different scenarios and have a way > to know automatically in the future if > - we fixed all them > - or we have a regression and broke some. > > On Wed, Nov 15, 2017 at 10:44 AM, Thomas Dupriez < > thomas.dupriez(a)ens-paris-saclay.fr> wrote: > >> >> >> Le 15/11/2017 Ã 01:19, Ben Coman a Ã©crit : >> >> >> >> On 14 November 2017 at 23:55, Thomas Dupriez < >> thomas.dupriez(a)ens-paris-saclay.fr> wrote: >> >>> While working on writing a test, I discovered that just using >>> stepThrough instead of stepOver may not be the definitive solution. >>> >>> # Example1: When using the `value` message directly (instead of calling >>> a method that does that as in my previous example), the RunToHere moves the >>> debugSession to the `value` message and not the inside of the block. >>> >>> `meth2 >>> self halt. >>> [ >>> 1+1. >>> 2+2."< cursor before the RunToHere" >>> ] ">"value"<result of the RunToHere". >>> 3+3. >>> "Two stepInto are required after the RunToHere to reach the cursor >>> (the `+2` message)"` >>> >>> # Example2: Going back to using a dedicated method for evaluating the >>> block, but increasing the block's size. The RunToHere moves the >>> debugSession to the first message of the block instead of the pointed one. >>> >>> `meth3 >>> self halt. >>> MyClass new evalBlock: >>> [ >>> 1">"+1"< result of the RunToHere". >>> 2+2."< cursor before the RunToHere" >>> ]. >>> 3+3. >>> "One stepInto is required after the RunToHere to reach the cursor >>> (the `+2` message)"` >>> >>> cheers -thomas >>> >> >> In both cases, what happens with an additional step-Through? >> >> cheers -ben >> >> >> # Example1*: >> Operation: RunToHere with cursor at the end of the `2+2.` line + 1 >> stepThrough. >> Result: DebugSession at the `+1`, first instruction of the block but not >> the intended position. >> Note: Doing an additional stepThrough brings the debugSession to the >> intended `+2`. >> >> `meth2 >> self halt. >> [ >> 1">"+1"<"."result of the RunToHere + 1 stepThrough" >> 2+2."< cursor before the RunToHere" >> ] ">"value"<result of the RunToHere". >> 3+3. >> "Two stepInto are required after the RunToHere to reach the cursor >> (the `+2` message)"` >> >> # Example2*: >> Operation: RunToHere with cursor at the end of the `2+2.` line + 1 >> stepThrough >> Result: DebugSession at the intended `+2` position. >> Note: The additional stepThrough just moves the DebugSession to the next >> instruction. See Example3 for what happens when the target instruction is >> further away. >> >> `meth3 >> self halt. >> MyClass new evalBlock: >> [ >> 1">"+1"< result of the RunToHere". >> 2">"+2"<result of RunToHere+1stepThrough"."< cursor before the >> RunToHere" >> ]. >> 3+3. >> "One stepInto is required after the RunToHere to reach the cursor >> (the `+2` message)"` >> >> >> # Example3: >> Operation: RunToHere with cursor at the end of the `3+3.` line. + 1 >> stepThrough. >> Result: DebugSession is at the `+2` instruction, not the intended `+3` >> one. >> >> `meth4 >> self halt. >> MyClass new evalBlock: >> [ >> 1">"+1"< result of the RunToHere". >> 2">"+2"<result of RunToHere+1stepThrough". >> 3">"+3"<result of RunToHere+2stepThrough"."< cursor before the >> RunToHere" >> ]. >> 4+4. >> "One stepInto is required after the RunToHere to reach the cursor >> (the `+2` message)"` >> >> cheers -thomas >> >> Le 13/11/2017 Ã 17:23, Thomas Dupriez a Ã©crit : >>> >>> >>> >>> Le 13/11/2017 Ã 15:56, Ben Coman a Ã©crit : >>> >>> >>> >>> On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez < >>> thomas.dupriez(a)ens-paris-saclay.fr> wrote: >>> >>>> >>>> >>>> Le 13/11/2017 Ã 14:08, Ben Coman a Ã©crit : >>>> >>>> >>>> >>>> On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez < >>>> thomas.dupriez(a)ens-paris-saclay.fr> wrote: >>>> >>>>> I dug a bit in this issue. Here are the results: >>>>> >>>>> >>>>> # Problem raised by Stephanne >>>>> Code like the following is open in the debugger: >>>>> >>>>> `myMethod >>>>> 1+1. <PROGRAMCOUNTER> >>>>> MyClass new myEvalBlock: [ >>>>> 2+2. <CURSOR> >>>>> ]. >>>>> 3+3.` >>>>> >>>>> The program counter is on the 1+1, the cursor is at the end of the 2+2 >>>>> line. >>>>> Right-click, "Run to here". >>>>> -> the program counter moves to the 3+3, and does not stop at the 2+2 >>>>> (where the cursor is). Even though the 2+2 does get evaluated (the >>>>> myEvalBlock method evaluates the blocks it receives). >>>>> If there was no code after the block, the debugger would jump back to >>>>> the caller of myMethod. >>>>> >>>>> # Why this happens >>>>> The implementation of RunToHere (source code below) is basically to >>>>> stepOver until the context is different or the source code position of the >>>>> program counter is higher or equal to the source code position of the >>>>> cursor/selection. >>>>> >>>>> Since the debugger uses stepOver, it executes myEvalBlock without >>>>> stopping, reaches the 3+3 and see it has gone further than the source code >>>>> position of the cursorm so it stops. >>>>> >>>>> Source code of DebugSession>>#runToSelection:inContext: >>>>> >>>>> `runToSelection: selectionInterval inContext: aContext >>>>> "Attempt to step over instructions in selectedContext until the >>>>> execution reaches the selected instruction. This happens when >>>>> the >>>>> program counter passes the begining of selectionInterval. >>>>> >>>>> A not nill and valid interval is expected." >>>>> >>>>> (self pcRangeForContext: aContext) first >= selectionInterval >>>>> first >>>>> ifTrue: [ ^self ]. >>>>> self stepOver: aContext. >>>>> [ aContext == self interruptedContext and: [ (self >>>>> pcRangeForContext: aContext) first < selectionInterval first ] ] >>>>> whileTrue: [ self stepOver: aContext ]` >>>>> >>>>> # Observations and thoughts >>>>> - Replacing the stepOver with a stepInto -> This made the RunToHere >>>>> stops when resolving the 'new' message (because the context changes). >>>>> >>>> >>>> Thanks for looking into this Thomas. >>>> What happens if you use stepThrough rather than stepInto? >>>> >>>> cheers -ben >>>> >>>> >>>> Using `stepThrough: aContext` instead of `stepInto: aContext`, the >>>> RunToHere in the block stops at the intended place: the 2+2. >>>> Printing the sequence of `self pcRangeForContext: aContext` yields the >>>> following. It doesn't show precisely the stop in the block, and instead >>>> shows an interval encompassing the whole block. That's what I was using to >>>> see where the execution was going during the RunToHere loop so I guess >>>> that's not a precise enough indicator for this situation... >>>> (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) >>>> >>>> I also tried the case where the block does not get evaluated (changing >>>> myEvalBlock so that it does nothing). In this situation, the RunToHere with >>>> a stepThrough ends up at the intended place, the 3+3. >>>> >>>> So... just use stepThrough for the RunToHere I guess? >>>> >>> >>> Seems like expected behaviour. >>> Could you create an Issue/Pull Request to provide some concrete code to >>> review? >>> >>> Now the trick will be if you can devise some tests to go with this. >>> For examples perhaps look at senders of newDebugSessionNamed:startedAt: >>> including SpecDebugger>>testBasic. >>> >>> cheers -ben >>> >>> >>> >>> I opened an issue on FogBugz: https://pharo.fogbugz.com/f/cases/20687/ >>> >>> Attached are the file out of the test code (MyClass.st) and the fixed >>> runToSelection:inContext: (DebugSession-runToSelectioninContext). >>> I'll make a pull request tomorrow. >>> >>> For the test, I'm thinking about something like the following, that >>> checks the source code position of the pc after the runToSelection. (It's >>> not working yet) >>> Now that I think of it, the source code position of the pc will maybe be >>> the whole block (as experienced earlier) so this approach may end up not >>> working. >>> I'll come back to that tomorrow. >>> >>> Draft for a test: >>> `testRunToSelectionInContext >>> |context_ process_ session_| >>> "The variable names have an underscore to distinguish them from >>> those declared in the setUp method of this TestCase (DebuggerModelTest), >>> which are not suited for this test (because not making a debug session out >>> of suitable code)" >>> context_ := [1+1. >>> self evalBlock:[2+2]. >>> 3+3. >>> ] asContext. >>> process_ := Process >>> forContext: context_ >>> priority: Processor userInterruptPriority. >>> >>> session_:= process_ newDebugSessionNamed: 'test session' startedAt: >>> context_. >>> session_ runToSelection: (Interval from: 28 to: 27) inContext: >>> context_. >>> self assert: ((session_ pcRangeForContext: context_) first == 3)` >>> >>> cheers - Thomas >>> >>> >>>> Thomas >>>> >>>> >>>> >>>> >>>> >>>>> - Replacing the stepOver with stepInto and removing the equal >>>>> condition on contexts -> The RunToHere goes to the 3+3. Looking at the >>>>> source code position of the program counter, it doesn't enter the block and >>>>> seems to resolve it in a single step. I don't really get why that is, >>>>> considering using the stepInto button of the debugger does enter the block. >>>>> Here is the series of source code positions of the program counter during >>>>> the RunToHere: (21 to: 22)(34 to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 >>>>> to: 60)(65 to: 66). >>>>> However, removing the equal condition on contexts means that if the >>>>> method call returns before reaching the cursor, it won't stop! >>>>> >>>>> - An idea could be to have the RunToHere place a metalink on the >>>>> selected node and let the execution run until it hits the metalink, which >>>>> then updates the debugger. Potential problems are that it implies >>>>> installing a metalink on a method that is already on the stack, which may >>>>> not be that easy to do properly (in particular, it affects the program >>>>> counter since it changes the bytecode), and there is the potential case >>>>> where the metalink is never reached (for example imagine the myEvalBlock: >>>>> method of my example is just storing the block and not evaluating it). >>>>> >>>>> >>>>> Cheers, >>>>> Thomas >>>>> >>>>> >>>>> >>>>> Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©crit : >>>>> >>>>>> Agreed. Thomas? It would be a good bone to ... (Un bon os a ronger) . >>>>>> >>>>>> Stef >>>>>> >>>>>> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> The basic tools, such as debugger, are expected to work. If >>>>>>> something does not work, itâs a bug. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim(a)testit.works> >>>>>>>> <tim(a)testit.works> wrote: >>>>>>>> >>>>>>>> I think it's broken in Pharo 6 too, as I often find it unreliable. >>>>>>>> >>>>>>>> It's hard to know what should work anymore - we really need a >>>>>>>> stabilisation release to let the dust settle. >>>>>>>> >>>>>>>> I'm always a bit reticent to report things as I'm not sure what you >>>>>>>> expect to work. >>>>>>>> >>>>>>>> Tim >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> I have the following method and I have my cursor -MY CURSOR HERE- >>>>>>>>> I select the menu run to here and .... I exit the method. >>>>>>>>> :( >>>>>>>>> >>>>>>>>> Is run to here working in Pharo 70? >>>>>>>>> I start to get worry about the number of bugs I get when using >>>>>>>>> Pharo70. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> fileOut >>>>>>>>> "File out the receiver, to a file whose name is a function of the >>>>>>>>> change-set name and a unique numeric tag." >>>>>>>>> >>>>>>>>> | nameToUse | >>>>>>>>> self halt. >>>>>>>>> self class promptForDefaultChangeSetDirectoryIfNecessary. >>>>>>>>> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >>>>>>>>> nextVersion basename. >>>>>>>>> UIManager default >>>>>>>>> showWaitCursorWhile: >>>>>>>>> [ >>>>>>>>> | internalStream | >>>>>>>>> internalStream := (String new: 10000) writeStream. >>>>>>>>> >>>>>>>>> -MY CURSOR HERE- >>>>>>>>> >>>>>>>>> internalStream >>>>>>>>> header; >>>>>>>>> timeStamp. >>>>>>>>> self fileOutPreambleOn: internalStream. >>>>>>>>> self fileOutOn: internalStream. >>>>>>>>> self fileOutPostscriptOn: internalStream. >>>>>>>>> CodeExporter >>>>>>>>> writeSourceCodeFrom: internalStream >>>>>>>>> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >>>>>>>>> isSt: false ] >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.feenk.com >>>>>>> >>>>>>> "Value is always contextual." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 16, 2017

Pharo 6.1 crashing on Windows 10.

by Benoit St-Jean

Downloaded the 6.1 version of Pharo for Windows.Â I've been loading code, writing code, browsing, checking new tools, etc for about an 2 hours without problem and now, the second I start the environment, it crashes!Â See screenshot and dump file attached ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".Â (A. Einstein)

Nov. 16, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Sven Van Caekenberghe

> On 15 Nov 2017, at 22:47, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2017-11-15 22:27 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Alistair, > > Are steps 8 & 9 needed, since the latest image should be in sync with the latest dev version, no ? > > 8) the latest build may not be created from the latest merged commit. This step is not necessary because Iceberg can handle such situations and moreover it can do cherry-picking during commits. However personally I use it because it reduces probability of troubles. As always, it is good to execute it only if you know what you are doing and what you want. > > 9) is not needed anymore > > BTW, Guille wrote a very nice document about your fork synchronization > https://github.com/guillep/PharoIntegrationProcess/wiki/Keep-your-repo-in-s… I ended up using those instructions $ git checkout development $ git pull https://github.com/pharo-project/pharo.git development $ git push https://github.com/svenvc/pharo.git development I guess that is exactly what the Pharo code does. This feels better. Thx! > -- Pavel > > > Sven > > @Pavel, thanks as well. A lot seems possible with the API. > > I hope to be able to try later tonight. > > > On 15 Nov 2017, at 21:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Sven, > > > > On 15 November 2017 at 20:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Yes, it is working for me too now, and it is actually pretty nice. > >> > >> I wonder though what the best way is to keep your personal fork up to date ? > >> > >> I managed to do it with a PR from the fork to the origin (or is it the reverse ?), like this > >> > >> https://github.com/svenvc/pharo/pull/1 > >> > >> but it felt a bit weird because obviously the diff is large and I had the impression that the CI process than had to process all this. > >> > >> Maybe there is a better/easier/more correct way ? > > > > I only update my fork when I'm starting from a fresh image - my > > understanding is that upgrading an image is not supported at the > > moment. > > > > Set up the repository: > > > > cd emptydirectory > > wget 'the latest 7.0 image' > > git clone git@github.com:pharo-project/pharo.git pharo-core > > cd pharo-core > > git remote add $username git@github.com:$username/pharo.git > > cd .. > > > > Once the repository has been set up, the following script: > > > > 1. Configures Iceberg to show system repositories > > 2. Finds the pharo repository. > > 3. Finds the two remotes (origin and $username, from above) > > 4. Configures Iceberg to pull from origin and push to $username by default. > > 5. Checks out the development branch > > > > and finally does what you were asking about, updating the fork from the origin > > > > 6. Pull from origin > > 7. Push to fork ($username) > > 8, Checkout the images commit > > 9. Reloads modified packages > > > > > > | location username pharoRepository origin myfork | > > > > location := 'pharo-core'. > > username := 'myusername'. > > > > Iceberg showSystemRepositories: true. > > pharoRepository := IceRepository registry detect: [ :each | each name > > = 'pharo' ]. > > pharoRepository location: location asFileReference. > > origin := pharoRepository remotes detect: [ :each | each remoteName = > > 'origin' ]. > > myfork := pharoRepository remotes detect: [ :each | each remoteName = > > username ]. > > pharoRepository pushRemote: myfork. > > pharoRepository pullRemote: origin. > > pharoRepository checkoutBranch: 'development'. > > pharoRepository backend pullFrom: origin. > > pharoRepository push. > > pharoRepository checkoutBranch: (SystemVersion current commitHash). > > [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded > > and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning > > do: [ :warning | warning resume: true ]. > > > > 'Loaded pharo-core' inspect. > > > > > > I always have OSSubprocess loaded, so it would actually be easy to > > automate the cloning and configuration of the repository. I might do > > that next week. > > > > Cheers, > > Alistair > > > > > > > >>> On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >>> > >>> Just to add a positive note to this discussion: > >>> > >>> After cloning the pharo repository, adding my fork as a remote and > >>> using Guille's scripts from earlier this year to configure the > >>> repositories in image, I was able to: > >>> > >>> - Create new branch from Fogbugz issue... > >>> - Make the changes > >>> - Push the changes up to my fork (Synchronise repository) > >>> - Create pull request... > >>> - Make some more changes > >>> - Push changes to my fork > >>> > >>> All from within the image, without any problems. > >>> > >>> There's still plenty that is manual and outside the image, and it > >>> would be nice to have a GUI that guided you through the process (at > >>> the moment you need to know what steps to do and in what order), but > >>> we have a good solid basis for moving forward. > >>> > >>> Cheers, > >>> Alistair > >>> > >>> > >>> > >>> On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>> > >>>> > >>>>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >>>>> > >>>>> Sven > >>>>> > >>>>> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce > >>>>> the pain for me. > >>>> > >>>> Ah, OK, found it. Thanks. > >>>> > >>>> Nice document BTW ;-) > >>>> > >>>>> Stef > >>>>> > >>>>> > >>>>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >>>>> > >>>>> > >>>>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >>>>>> > >>>>>> If you give me precise instructions I can update the post :) > >>>>> > >>>>> precise instructions is: > >>>>> - do not use https, use ssh > >>>>> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. > >>>>> > >>>>>> > >>>>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>>>> I think I succeeded: > >>>>>> > >>>>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments > >>>>>> https://github.com/pharo-project/pharo/pull/420 > >>>>>> > >>>>>> It does contain 4 identical commits due to my troubles earlier on. > >>>>>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. > >>>>>> > >>>>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >>>>>>>> > >>>>>>>> hi, > >>>>>>>> > >>>>>>>> thing is, you should not use https authentication (and the guide should not point to it) > >>>>>>>> Using SSH mode works out of the box. > >>>>>>>> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) > >>>>>>> > >>>>>>> Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. > >>>>>>> > >>>>>>> Thanks ! > >>>>>>> > >>>>>>>> Esteban > >>>>>>>> > >>>>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. > >>>>>>>>> > >>>>>>>>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. > >>>>>>>>> > >>>>>>>>> $ sw_vers > >>>>>>>>> ProductName: Mac OS X > >>>>>>>>> ProductVersion: 10.13 > >>>>>>>>> BuildVersion: 17A405 > >>>>>>>>> > >>>>>>>>> $ curl get.pharo.org/70+vm | bash > >>>>>>>>> ... > >>>>>>>>> > >>>>>>>>> $ ./pharo-ui Pharo.image > >>>>>>>>> > >>>>>>>>> I now have the following setup, which is correct I think. > >>>>>>>>> > >>>>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> > >>>>>>>>> > >>>>>>>>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. > >>>>>>>>> > >>>>>>>>> Locally, I see > >>>>>>>>> > >>>>>>>>> $ git status > >>>>>>>>> On branch 20613-Improve-some-UUID-comments > >>>>>>>>> nothing to commit, working tree clean > >>>>>>>>> > >>>>>>>>> with the new code already committed > >>>>>>>>> > >>>>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st > >>>>>>>>> instance creation > >>>>>>>>> new > >>>>>>>>> "Create and return a new UUID" > >>>>>>>>> > >>>>>>>>> "self new" > >>>>>>>>> > >>>>>>>>> ^ (self new: 16) > >>>>>>>>> > >>>>>>>>> What did I do wrong ? How do I proceed ? > >>>>>>>>> > >>>>>>>>> Sven > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> Guille Polito > >>>>>> Research Engineer > >>>>>> > >>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille > >>>>>> CRIStAL - UMR 9189 > >>>>>> French National Center for Scientific Research - http://www.cnrs.fr > >>>>>> > >>>>>> Web: http://guillep.github.io > >>>>>> Phone: +33 06 52 70 66 13 > > >

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Pavel Krivanek

2017-11-15 22:46 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Sven, > > On 15 November 2017 at 22:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Alistair, > > > > Are steps 8 & 9 needed, since the latest image should be in sync with > the latest dev version, no ? > > Until the next commit is made :-) > > Step 8 is not strictly needed, but if it is omitted the code in the > image may not match the code in the repository, and loading / saving > core packages may result in an inconsistent state. > > Step 9 was added because at one point the image had some packages > marked as dirty. I'm not sure if that is still the case. > It is not. I sometimes use modified version of these lines to reaload all packages to make them in sync with a particular branch after switching to it because if you reload all packages from the Iceberg UI, it may require clicking on a lot of confirmation windows. -- Pavel > Cheers, > Alistair > > > > Sven > > > > @Pavel, thanks as well. A lot seems possible with the API. > > > > I hope to be able to try later tonight. > > > >> On 15 Nov 2017, at 21:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: > >> > >> Hi Sven, > >> > >> On 15 November 2017 at 20:44, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>> Yes, it is working for me too now, and it is actually pretty nice. > >>> > >>> I wonder though what the best way is to keep your personal fork up to > date ? > >>> > >>> I managed to do it with a PR from the fork to the origin (or is it the > reverse ?), like this > >>> > >>> https://github.com/svenvc/pharo/pull/1 > >>> > >>> but it felt a bit weird because obviously the diff is large and I had > the impression that the CI process than had to process all this. > >>> > >>> Maybe there is a better/easier/more correct way ? > >> > >> I only update my fork when I'm starting from a fresh image - my > >> understanding is that upgrading an image is not supported at the > >> moment. > >> > >> Set up the repository: > >> > >> cd emptydirectory > >> wget 'the latest 7.0 image' > >> git clone git@github.com:pharo-project/pharo.git pharo-core > >> cd pharo-core > >> git remote add $username git@github.com:$username/pharo.git > >> cd .. > >> > >> Once the repository has been set up, the following script: > >> > >> 1. Configures Iceberg to show system repositories > >> 2. Finds the pharo repository. > >> 3. Finds the two remotes (origin and $username, from above) > >> 4. Configures Iceberg to pull from origin and push to $username by > default. > >> 5. Checks out the development branch > >> > >> and finally does what you were asking about, updating the fork from the > origin > >> > >> 6. Pull from origin > >> 7. Push to fork ($username) > >> 8, Checkout the images commit > >> 9. Reloads modified packages > >> > >> > >> | location username pharoRepository origin myfork | > >> > >> location := 'pharo-core'. > >> username := 'myusername'. > >> > >> Iceberg showSystemRepositories: true. > >> pharoRepository := IceRepository registry detect: [ :each | each name > >> = 'pharo' ]. > >> pharoRepository location: location asFileReference. > >> origin := pharoRepository remotes detect: [ :each | each remoteName = > >> 'origin' ]. > >> myfork := pharoRepository remotes detect: [ :each | each remoteName = > >> username ]. > >> pharoRepository pushRemote: myfork. > >> pharoRepository pullRemote: origin. > >> pharoRepository checkoutBranch: 'development'. > >> pharoRepository backend pullFrom: origin. > >> pharoRepository push. > >> pharoRepository checkoutBranch: (SystemVersion current commitHash). > >> [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded > >> and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning > >> do: [ :warning | warning resume: true ]. > >> > >> 'Loaded pharo-core' inspect. > >> > >> > >> I always have OSSubprocess loaded, so it would actually be easy to > >> automate the cloning and configuration of the repository. I might do > >> that next week. > >> > >> Cheers, > >> Alistair > >> > >> > >> > >>>> On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >>>> > >>>> Just to add a positive note to this discussion: > >>>> > >>>> After cloning the pharo repository, adding my fork as a remote and > >>>> using Guille's scripts from earlier this year to configure the > >>>> repositories in image, I was able to: > >>>> > >>>> - Create new branch from Fogbugz issue... > >>>> - Make the changes > >>>> - Push the changes up to my fork (Synchronise repository) > >>>> - Create pull request... > >>>> - Make some more changes > >>>> - Push changes to my fork > >>>> > >>>> All from within the image, without any problems. > >>>> > >>>> There's still plenty that is manual and outside the image, and it > >>>> would be nice to have a GUI that guided you through the process (at > >>>> the moment you need to know what steps to do and in what order), but > >>>> we have a good solid basis for moving forward. > >>>> > >>>> Cheers, > >>>> Alistair > >>>> > >>>> > >>>> > >>>> On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>> > >>>>> > >>>>>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >>>>>> > >>>>>> Sven > >>>>>> > >>>>>> have a look at the TipsAndTricks new booklet available at > http://books.pharo.org. There is a configuration for iceberg that sets > and reduce > >>>>>> the pain for me. > >>>>> > >>>>> Ah, OK, found it. Thanks. > >>>>> > >>>>> Nice document BTW ;-) > >>>>> > >>>>>> Stef > >>>>>> > >>>>>> > >>>>>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano < > estebanlm(a)gmail.com> wrote: > >>>>>> > >>>>>> > >>>>>>> On 31 Oct 2017, at 10:37, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >>>>>>> > >>>>>>> If you give me precise instructions I can update the post :) > >>>>>> > >>>>>> precise instructions is: > >>>>>> - do not use https, use ssh > >>>>>> - if you do not follow our recommendation and you insist on use > https, add your credentials before doing any commit. > >>>>>> > >>>>>>> > >>>>>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe < > sven(a)stfx.eu> wrote: > >>>>>>> I think I succeeded: > >>>>>>> > >>>>>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments > >>>>>>> https://github.com/pharo-project/pharo/pull/420 > >>>>>>> > >>>>>>> It does contain 4 identical commits due to my troubles earlier on. > >>>>>>> I also did not see a confirmation by way of an #inform: after the > pull request in Iceberg. > >>>>>>> > >>>>>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>>>>>>>> > >>>>>>>>> hi, > >>>>>>>>> > >>>>>>>>> thing is, you should not use https authentication (and the guide > should not point to it) > >>>>>>>>> Using SSH mode works out of the box. > >>>>>>>>> Using HTTPS there is currently a bug and the workaround is to > introduce your credentials *before* trying to commit (in settings) > >>>>>>>> > >>>>>>>> Well, after entering my username/password in Settings > Tools > > Software Configuration Management > Iceberg > Plaintext Credentials I am > one step further - I managed to 'Commit & Push'. > >>>>>>>> > >>>>>>>> Thanks ! > >>>>>>>> > >>>>>>>>> Esteban > >>>>>>>>> > >>>>>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the > new way. > >>>>>>>>>> > >>>>>>>>>> I was following https://github.com/guillep/ > PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo and I got stuck > just before step 3, after trying to do "That will calculate the differences > between the checked-out branch and your image, show you the tree with the > differences and let you commit (and push)". Specifically, the 'and push' > fails. > >>>>>>>>>> > >>>>>>>>>> $ sw_vers > >>>>>>>>>> ProductName: Mac OS X > >>>>>>>>>> ProductVersion: 10.13 > >>>>>>>>>> BuildVersion: 17A405 > >>>>>>>>>> > >>>>>>>>>> $ curl get.pharo.org/70+vm | bash > >>>>>>>>>> ... > >>>>>>>>>> > >>>>>>>>>> $ ./pharo-ui Pharo.image > >>>>>>>>>> > >>>>>>>>>> I now have the following setup, which is correct I think. > >>>>>>>>>> > >>>>>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> > >>>>>>>>>> > >>>>>>>>>> I can commit on my local branch (left button), but when I try > to do the 'and Push' (right button), things hang after I enter my > credentials. > >>>>>>>>>> > >>>>>>>>>> Locally, I see > >>>>>>>>>> > >>>>>>>>>> $ git status > >>>>>>>>>> On branch 20613-Improve-some-UUID-comments > >>>>>>>>>> nothing to commit, working tree clean > >>>>>>>>>> > >>>>>>>>>> with the new code already committed > >>>>>>>>>> > >>>>>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st > >>>>>>>>>> instance creation > >>>>>>>>>> new > >>>>>>>>>> "Create and return a new UUID" > >>>>>>>>>> > >>>>>>>>>> "self new" > >>>>>>>>>> > >>>>>>>>>> ^ (self new: 16) > >>>>>>>>>> > >>>>>>>>>> What did I do wrong ? How do I proceed ? > >>>>>>>>>> > >>>>>>>>>> Sven > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Guille Polito > >>>>>>> Research Engineer > >>>>>>> > >>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille > >>>>>>> CRIStAL - UMR 9189 > >>>>>>> French National Center for Scientific Research - > http://www.cnrs.fr > >>>>>>> > >>>>>>> Web: http://guillep.github.io > >>>>>>> Phone: +33 06 52 70 66 13 > > > > > >

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Pavel Krivanek

2017-11-15 22:27 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Alistair, > > Are steps 8 & 9 needed, since the latest image should be in sync with the > latest dev version, no ? > 8) the latest build may not be created from the latest merged commit. This step is not necessary because Iceberg can handle such situations and moreover it can do cherry-picking during commits. However personally I use it because it reduces probability of troubles. As always, it is good to execute it only if you know what you are doing and what you want. 9) is not needed anymore BTW, Guille wrote a very nice document about your fork synchronization https://github.com/guillep/PharoIntegrationProcess/wiki/Keep-your-repo -in-sync -- Pavel > Sven > > @Pavel, thanks as well. A lot seems possible with the API. > > I hope to be able to try later tonight. > > > On 15 Nov 2017, at 21:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Sven, > > > > On 15 November 2017 at 20:44, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Yes, it is working for me too now, and it is actually pretty nice. > >> > >> I wonder though what the best way is to keep your personal fork up to > date ? > >> > >> I managed to do it with a PR from the fork to the origin (or is it the > reverse ?), like this > >> > >> https://github.com/svenvc/pharo/pull/1 > >> > >> but it felt a bit weird because obviously the diff is large and I had > the impression that the CI process than had to process all this. > >> > >> Maybe there is a better/easier/more correct way ? > > > > I only update my fork when I'm starting from a fresh image - my > > understanding is that upgrading an image is not supported at the > > moment. > > > > Set up the repository: > > > > cd emptydirectory > > wget 'the latest 7.0 image' > > git clone git@github.com:pharo-project/pharo.git pharo-core > > cd pharo-core > > git remote add $username git@github.com:$username/pharo.git > > cd .. > > > > Once the repository has been set up, the following script: > > > > 1. Configures Iceberg to show system repositories > > 2. Finds the pharo repository. > > 3. Finds the two remotes (origin and $username, from above) > > 4. Configures Iceberg to pull from origin and push to $username by > default. > > 5. Checks out the development branch > > > > and finally does what you were asking about, updating the fork from the > origin > > > > 6. Pull from origin > > 7. Push to fork ($username) > > 8, Checkout the images commit > > 9. Reloads modified packages > > > > > > | location username pharoRepository origin myfork | > > > > location := 'pharo-core'. > > username := 'myusername'. > > > > Iceberg showSystemRepositories: true. > > pharoRepository := IceRepository registry detect: [ :each | each name > > = 'pharo' ]. > > pharoRepository location: location asFileReference. > > origin := pharoRepository remotes detect: [ :each | each remoteName = > > 'origin' ]. > > myfork := pharoRepository remotes detect: [ :each | each remoteName = > > username ]. > > pharoRepository pushRemote: myfork. > > pharoRepository pullRemote: origin. > > pharoRepository checkoutBranch: 'development'. > > pharoRepository backend pullFrom: origin. > > pharoRepository push. > > pharoRepository checkoutBranch: (SystemVersion current commitHash). > > [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded > > and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning > > do: [ :warning | warning resume: true ]. > > > > 'Loaded pharo-core' inspect. > > > > > > I always have OSSubprocess loaded, so it would actually be easy to > > automate the cloning and configuration of the repository. I might do > > that next week. > > > > Cheers, > > Alistair > > > > > > > >>> On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >>> > >>> Just to add a positive note to this discussion: > >>> > >>> After cloning the pharo repository, adding my fork as a remote and > >>> using Guille's scripts from earlier this year to configure the > >>> repositories in image, I was able to: > >>> > >>> - Create new branch from Fogbugz issue... > >>> - Make the changes > >>> - Push the changes up to my fork (Synchronise repository) > >>> - Create pull request... > >>> - Make some more changes > >>> - Push changes to my fork > >>> > >>> All from within the image, without any problems. > >>> > >>> There's still plenty that is manual and outside the image, and it > >>> would be nice to have a GUI that guided you through the process (at > >>> the moment you need to know what steps to do and in what order), but > >>> we have a good solid basis for moving forward. > >>> > >>> Cheers, > >>> Alistair > >>> > >>> > >>> > >>> On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>> > >>>> > >>>>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >>>>> > >>>>> Sven > >>>>> > >>>>> have a look at the TipsAndTricks new booklet available at > http://books.pharo.org. There is a configuration for iceberg that sets > and reduce > >>>>> the pain for me. > >>>> > >>>> Ah, OK, found it. Thanks. > >>>> > >>>> Nice document BTW ;-) > >>>> > >>>>> Stef > >>>>> > >>>>> > >>>>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano < > estebanlm(a)gmail.com> wrote: > >>>>> > >>>>> > >>>>>> On 31 Oct 2017, at 10:37, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >>>>>> > >>>>>> If you give me precise instructions I can update the post :) > >>>>> > >>>>> precise instructions is: > >>>>> - do not use https, use ssh > >>>>> - if you do not follow our recommendation and you insist on use > https, add your credentials before doing any commit. > >>>>> > >>>>>> > >>>>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe < > sven(a)stfx.eu> wrote: > >>>>>> I think I succeeded: > >>>>>> > >>>>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments > >>>>>> https://github.com/pharo-project/pharo/pull/420 > >>>>>> > >>>>>> It does contain 4 identical commits due to my troubles earlier on. > >>>>>> I also did not see a confirmation by way of an #inform: after the > pull request in Iceberg. > >>>>>> > >>>>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>>>>>>> > >>>>>>>> hi, > >>>>>>>> > >>>>>>>> thing is, you should not use https authentication (and the guide > should not point to it) > >>>>>>>> Using SSH mode works out of the box. > >>>>>>>> Using HTTPS there is currently a bug and the workaround is to > introduce your credentials *before* trying to commit (in settings) > >>>>>>> > >>>>>>> Well, after entering my username/password in Settings > Tools > > Software Configuration Management > Iceberg > Plaintext Credentials I am > one step further - I managed to 'Commit & Push'. > >>>>>>> > >>>>>>> Thanks ! > >>>>>>> > >>>>>>>> Esteban > >>>>>>>> > >>>>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the > new way. > >>>>>>>>> > >>>>>>>>> I was following https://github.com/guillep/ > PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo and I got stuck > just before step 3, after trying to do "That will calculate the differences > between the checked-out branch and your image, show you the tree with the > differences and let you commit (and push)". Specifically, the 'and push' > fails. > >>>>>>>>> > >>>>>>>>> $ sw_vers > >>>>>>>>> ProductName: Mac OS X > >>>>>>>>> ProductVersion: 10.13 > >>>>>>>>> BuildVersion: 17A405 > >>>>>>>>> > >>>>>>>>> $ curl get.pharo.org/70+vm | bash > >>>>>>>>> ... > >>>>>>>>> > >>>>>>>>> $ ./pharo-ui Pharo.image > >>>>>>>>> > >>>>>>>>> I now have the following setup, which is correct I think. > >>>>>>>>> > >>>>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> > >>>>>>>>> > >>>>>>>>> I can commit on my local branch (left button), but when I try to > do the 'and Push' (right button), things hang after I enter my credentials. > >>>>>>>>> > >>>>>>>>> Locally, I see > >>>>>>>>> > >>>>>>>>> $ git status > >>>>>>>>> On branch 20613-Improve-some-UUID-comments > >>>>>>>>> nothing to commit, working tree clean > >>>>>>>>> > >>>>>>>>> with the new code already committed > >>>>>>>>> > >>>>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st > >>>>>>>>> instance creation > >>>>>>>>> new > >>>>>>>>> "Create and return a new UUID" > >>>>>>>>> > >>>>>>>>> "self new" > >>>>>>>>> > >>>>>>>>> ^ (self new: 16) > >>>>>>>>> > >>>>>>>>> What did I do wrong ? How do I proceed ? > >>>>>>>>> > >>>>>>>>> Sven > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> Guille Polito > >>>>>> Research Engineer > >>>>>> > >>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille > >>>>>> CRIStAL - UMR 9189 > >>>>>> French National Center for Scientific Research - http://www.cnrs.fr > >>>>>> > >>>>>> Web: http://guillep.github.io > >>>>>> Phone: +33 06 52 70 66 13 > > >

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Alistair Grant

Hi Sven, On 15 November 2017 at 22:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Alistair, > > Are steps 8 & 9 needed, since the latest image should be in sync with the latest dev version, no ? Until the next commit is made :-) Step 8 is not strictly needed, but if it is omitted the code in the image may not match the code in the repository, and loading / saving core packages may result in an inconsistent state. Step 9 was added because at one point the image had some packages marked as dirty. I'm not sure if that is still the case. Cheers, Alistair > Sven > > @Pavel, thanks as well. A lot seems possible with the API. > > I hope to be able to try later tonight. > >> On 15 Nov 2017, at 21:53, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Sven, >> >> On 15 November 2017 at 20:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Yes, it is working for me too now, and it is actually pretty nice. >>> >>> I wonder though what the best way is to keep your personal fork up to date ? >>> >>> I managed to do it with a PR from the fork to the origin (or is it the reverse ?), like this >>> >>> https://github.com/svenvc/pharo/pull/1 >>> >>> but it felt a bit weird because obviously the diff is large and I had the impression that the CI process than had to process all this. >>> >>> Maybe there is a better/easier/more correct way ? >> >> I only update my fork when I'm starting from a fresh image - my >> understanding is that upgrading an image is not supported at the >> moment. >> >> Set up the repository: >> >> cd emptydirectory >> wget 'the latest 7.0 image' >> git clone git@github.com:pharo-project/pharo.git pharo-core >> cd pharo-core >> git remote add $username git@github.com:$username/pharo.git >> cd .. >> >> Once the repository has been set up, the following script: >> >> 1. Configures Iceberg to show system repositories >> 2. Finds the pharo repository. >> 3. Finds the two remotes (origin and $username, from above) >> 4. Configures Iceberg to pull from origin and push to $username by default. >> 5. Checks out the development branch >> >> and finally does what you were asking about, updating the fork from the origin >> >> 6. Pull from origin >> 7. Push to fork ($username) >> 8, Checkout the images commit >> 9. Reloads modified packages >> >> >> | location username pharoRepository origin myfork | >> >> location := 'pharo-core'. >> username := 'myusername'. >> >> Iceberg showSystemRepositories: true. >> pharoRepository := IceRepository registry detect: [ :each | each name >> = 'pharo' ]. >> pharoRepository location: location asFileReference. >> origin := pharoRepository remotes detect: [ :each | each remoteName = >> 'origin' ]. >> myfork := pharoRepository remotes detect: [ :each | each remoteName = >> username ]. >> pharoRepository pushRemote: myfork. >> pharoRepository pullRemote: origin. >> pharoRepository checkoutBranch: 'development'. >> pharoRepository backend pullFrom: origin. >> pharoRepository push. >> pharoRepository checkoutBranch: (SystemVersion current commitHash). >> [(pharoRepository savedPackages select: [:aPackage | aPackage isLoaded >> and: [ aPackage isModified ]]) do: #reload ] on: MCMergeOrLoadWarning >> do: [ :warning | warning resume: true ]. >> >> 'Loaded pharo-core' inspect. >> >> >> I always have OSSubprocess loaded, so it would actually be easy to >> automate the cloning and configuration of the repository. I might do >> that next week. >> >> Cheers, >> Alistair >> >> >> >>>> On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>> >>>> Just to add a positive note to this discussion: >>>> >>>> After cloning the pharo repository, adding my fork as a remote and >>>> using Guille's scripts from earlier this year to configure the >>>> repositories in image, I was able to: >>>> >>>> - Create new branch from Fogbugz issue... >>>> - Make the changes >>>> - Push the changes up to my fork (Synchronise repository) >>>> - Create pull request... >>>> - Make some more changes >>>> - Push changes to my fork >>>> >>>> All from within the image, without any problems. >>>> >>>> There's still plenty that is manual and outside the image, and it >>>> would be nice to have a GUI that guided you through the process (at >>>> the moment you need to know what steps to do and in what order), but >>>> we have a good solid basis for moving forward. >>>> >>>> Cheers, >>>> Alistair >>>> >>>> >>>> >>>> On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> >>>>>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>>>> >>>>>> Sven >>>>>> >>>>>> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >>>>>> the pain for me. >>>>> >>>>> Ah, OK, found it. Thanks. >>>>> >>>>> Nice document BTW ;-) >>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>> >>>>>> >>>>>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>>>>> >>>>>>> If you give me precise instructions I can update the post :) >>>>>> >>>>>> precise instructions is: >>>>>> - do not use https, use ssh >>>>>> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >>>>>> >>>>>>> >>>>>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>> I think I succeeded: >>>>>>> >>>>>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>>>>>> https://github.com/pharo-project/pharo/pull/420 >>>>>>> >>>>>>> It does contain 4 identical commits due to my troubles earlier on. >>>>>>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>>>>>> >>>>>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>> hi, >>>>>>>>> >>>>>>>>> thing is, you should not use https authentication (and the guide should not point to it) >>>>>>>>> Using SSH mode works out of the box. >>>>>>>>> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>>>>>>> >>>>>>>> Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>>>>>>> >>>>>>>> Thanks ! >>>>>>>> >>>>>>>>> Esteban >>>>>>>>> >>>>>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>>>>>>>>> >>>>>>>>>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>>>>>>>>> >>>>>>>>>> $ sw_vers >>>>>>>>>> ProductName: Mac OS X >>>>>>>>>> ProductVersion: 10.13 >>>>>>>>>> BuildVersion: 17A405 >>>>>>>>>> >>>>>>>>>> $ curl get.pharo.org/70+vm | bash >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> $ ./pharo-ui Pharo.image >>>>>>>>>> >>>>>>>>>> I now have the following setup, which is correct I think. >>>>>>>>>> >>>>>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> >>>>>>>>>> >>>>>>>>>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>>>>>>>>> >>>>>>>>>> Locally, I see >>>>>>>>>> >>>>>>>>>> $ git status >>>>>>>>>> On branch 20613-Improve-some-UUID-comments >>>>>>>>>> nothing to commit, working tree clean >>>>>>>>>> >>>>>>>>>> with the new code already committed >>>>>>>>>> >>>>>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>>>>>>>>> instance creation >>>>>>>>>> new >>>>>>>>>> "Create and return a new UUID" >>>>>>>>>> >>>>>>>>>> "self new" >>>>>>>>>> >>>>>>>>>> ^ (self new: 16) >>>>>>>>>> >>>>>>>>>> What did I do wrong ? How do I proceed ? >>>>>>>>>> >>>>>>>>>> Sven >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Guille Polito >>>>>>> Research Engineer >>>>>>> >>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>>> CRIStAL - UMR 9189 >>>>>>> French National Center for Scientific Research - http://www.cnrs.fr >>>>>>> >>>>>>> Web: http://guillep.github.io >>>>>>> Phone: +33 06 52 70 66 13 > >

Nov. 15, 2017