- Pharo-dev - lists.pharo.org

[Pharo-project] pharo-2.0-tests Â» linux - Build # 329 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» mac - Build # 329 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

Re: [Pharo-project] integration/review process

by Frank Shearar

On 7 September 2012 11:52, Camillo Bruni <camillobruni(a)gmail.com> wrote: > previously: [Pharo-project] nil key in last literal in instance side methods (reproducible) > >> No, I'm just suggesting a poor man's simple diff in a mailing list, >> like squeak trunk. >> -1) inbox diff : you open a review to the whole community for comments, > > ok, why not on a separate mailing list that might make sense > >> -2) commit phase (whatever the checks you perform now are unchanged, >> except you have to take above review into account) >> -3) trunk diff : you open a last chance review (or post mortem >> analysis) to retract/correct commits > > that is (almost) up and running with our github export: > https://github.com/PharoProject/pharo-core > >> It's totally informal, and why would it work? You have to answer this >> question first: >> - how many people have ubiquitous web access to read the code and >> qualified enough to emit a useful comment? >> - how many people are downloading an image, updating to some version, >> opening a MC browser, browsing the diffs? >> >> You are proposing a much more ellaborated process to review code >> before integration. >> I agree, this information belongs to issue tracker. >> But formalizing and programming this process is involving (think about >> concurrent solution, roles, requests/answers timelines etc...) >> As you said, who will do it? > > >> From pragmatic POV, I prefer a light process that provides some help, >> than no help at all (which is close to what you get with current state >> of issue tracker). >> The code producing the diff and sendig the mail already exist, (you'll >> have to handle SLICE though)... Bonus: it's Smalltalk code. >> >> If you prefer to wait for something better, then let's wait... > > well the solution would be to simply switch to git for the whole version > management. github.com provides an excellent example of how to deal with > you aforementioned issues. > > - pull requests > - single commits > - full history > > plus > - everything can be commented / annotated from within the website => 0 setup needed > > > so for me something like github is the future for development. And in answer to Nicolas' comment about ubiquitous web access, GitHub can mail interested parties when something interesting happens - a new issue, issue state change, new comments - and you can reply to those via email. frank

Sept. 7, 2012

Re: [Pharo-project] Building a run loop that can continue after an unhanded exception

by Frank Shearar

On 7 September 2012 12:29, Joe Rickerby <joe.rickerby(a)square-i.net> wrote: > I have a solution however! Each timer on the run loop runs its action in a fork. This way any exception raised cannot unroll the stack to outside my run loop code. Right. That's effectively identical to using a delimited continuation: that marks the stack such that when you cut the continuation you can't capture past the stack marker. [1] The problem you might have is that the actions, being forked, run in a separate Process. That means you have to worry about synchronising - accessing common state from two actions (that are, of course, now running in parallel). frank [1] http://okmij.org/ftp/continuations/green-fork.html > On 7 Sep 2012, at 12:24, Joe Rickerby <joe.rickerby(a)squaregroup.co.uk> > wrote: > >> Not really. Proceed would take me back to where the exception was signalled. I want to resume at the point of the catch of the exception, no matter what happens regarding the exception. >> >> On 7 Sep 2012, at 09:40, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> On 07.09.2012 10:17, Joe Rickerby wrote: >>>> Hi all, >>>> >>>> I'm having a problem trying to build a run loop. If an exception is signalled within one of the run loop tasks, the exception escapes through the loop and terminates the process. >>>> >>>> I know I can catch the exception, and do something like print the message on the Transcript, but I was hoping to build something that was more helpful in development, allowing me to look through the stack, but if I press 'abandon' on that dialog, the run loop would continue from where I caught the exception. >>>> >>>> >>> Isn't that exactly what happens if you don't handle the error, and use the proceed button in (pre and normal) debugger windows? >>> >>> Cheers, >>> Henry >> > > >

Sept. 7, 2012

Re: [Pharo-project] git support

by Goubier Thierry

Le 07/09/2012 13:50, Camillo Bruni a Ã©crit : > > On 2012-09-07, at 13:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Le 07/09/2012 13:37, Camillo Bruni a Ã©crit : >>> >>> On 2012-09-07, at 13:29, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> Is using Git completely transparent so far? Or do I still need to manually write a "git push", "git pull" from the terminal? >>> >>> this is what is missing... we have the communication protocol for >>> downloading more or less ready, but we have to properly implement >>> the push. For the time being it works with an OSProcess call to `git push` >> >> That's transparent enough in my book. >> >>> but the goal is to have it completely transparent, otherwise I doubt >>> anybody will seriously use it from within pharo... >> >> OSProcess is a fine solution and it may be a tad easier to do it right. I would move to git if you get the transparent "OSProcess" working. > > ok that seems feasible :) Great ! And thanks for the effort. Thierry >>>> On Sep 7, 2012, at 8:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>>> who will help? >>>>> >>>>> max and I, stimulated by ESUG, worked on the latest version of FS-Git to make it stable again. >>>>> we are very close to have a complete set of git tools written in pharo ready! >>>>> >>>>> missing >>>>> ======= >>>>> - a better mc integration >>>>> - a cypress compatible fileout format >>>>> - complete interaction with the git protocol >>>>> - a direct way to commit stuff >>>>> >>>>> as always my time is somewhat limited as well and we're the only two developers working on it... >>>>> >>>>> The current work is available here: >>>>> http://ss3.gemstone.com/ss/FSGit-Experimental.html >>>>> https://github.com/dalehenrich/FSGit > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 7, 2012

Re: [Pharo-project] git support

by Camillo Bruni

On 2012-09-07, at 13:49, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 7 September 2012 12:15, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> who will help? >> >> max and I, stimulated by ESUG, worked on the latest version of FS-Git to make it stable again. >> we are very close to have a complete set of git tools written in pharo ready! >> >> missing >> ======= >> - a better mc integration >> - a cypress compatible fileout format >> - complete interaction with the git protocol >> - a direct way to commit stuff >> >> as always my time is somewhat limited as well and we're the only two developers working on it... >> >> The current work is available here: >> http://ss3.gemstone.com/ss/FSGit-Experimental.html >> https://github.com/dalehenrich/FSGit > > That's great news, Camillo! > > Is it at all possible to try separate (or keep separate) the core of > the Git-facing stuff from the UI code? Like - and I say this without > having looked at the structure of FS-Git, so feel free to yell at me > if necessary - keeping the UI code in a separate package: FSGit-Core > and FSGit-UI or whatever. there won't be any UI code, and there isn't any so far :) for the time being I will revamp the old MCGit interface, which simply wraps around a certain fileout format to recreate the mc snapshots.. > When moving code between Squeak and Pharo this is by far the most > painful part of the port. Well, it's not just Squeak that I'm thinking > of: so many projects would be useful in headless circumstances, and it > would be really nice to be able to not depend on UI code when you > don't need it. > > (Having had a look, I see that GitSmartHtppProtocol might have a typo > in its name?) yes indeed a typo (blush) :P

Sept. 7, 2012

Re: [Pharo-project] git support

by Camillo Bruni

On 2012-09-07, at 13:48, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 07/09/2012 13:37, Camillo Bruni a Ã©crit : >> >> On 2012-09-07, at 13:29, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> Is using Git completely transparent so far? Or do I still need to manually write a "git push", "git pull" from the terminal? >> >> this is what is missing... we have the communication protocol for >> downloading more or less ready, but we have to properly implement >> the push. For the time being it works with an OSProcess call to `git push` > > That's transparent enough in my book. > >> but the goal is to have it completely transparent, otherwise I doubt >> anybody will seriously use it from within pharo... > > OSProcess is a fine solution and it may be a tad easier to do it right. I would move to git if you get the transparent "OSProcess" working. ok that seems feasible :) >>> On Sep 7, 2012, at 8:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>>> who will help? >>>> >>>> max and I, stimulated by ESUG, worked on the latest version of FS-Git to make it stable again. >>>> we are very close to have a complete set of git tools written in pharo ready! >>>> >>>> missing >>>> ======= >>>> - a better mc integration >>>> - a cypress compatible fileout format >>>> - complete interaction with the git protocol >>>> - a direct way to commit stuff >>>> >>>> as always my time is somewhat limited as well and we're the only two developers working on it... >>>> >>>> The current work is available here: >>>> http://ss3.gemstone.com/ss/FSGit-Experimental.html >>>> https://github.com/dalehenrich/FSGit

Sept. 7, 2012

Re: [Pharo-project] git support

by Frank Shearar

On 7 September 2012 12:15, Camillo Bruni <camillobruni(a)gmail.com> wrote: > who will help? > > max and I, stimulated by ESUG, worked on the latest version of FS-Git to make it stable again. > we are very close to have a complete set of git tools written in pharo ready! > > missing > ======= > - a better mc integration > - a cypress compatible fileout format > - complete interaction with the git protocol > - a direct way to commit stuff > > as always my time is somewhat limited as well and we're the only two developers working on it... > > The current work is available here: > http://ss3.gemstone.com/ss/FSGit-Experimental.html > https://github.com/dalehenrich/FSGit That's great news, Camillo! Is it at all possible to try separate (or keep separate) the core of the Git-facing stuff from the UI code? Like - and I say this without having looked at the structure of FS-Git, so feel free to yell at me if necessary - keeping the UI code in a separate package: FSGit-Core and FSGit-UI or whatever. When moving code between Squeak and Pharo this is by far the most painful part of the port. Well, it's not just Squeak that I'm thinking of: so many projects would be useful in headless circumstances, and it would be really nice to be able to not depend on UI code when you don't need it. (Having had a look, I see that GitSmartHtppProtocol might have a typo in its name?) frank > best > cami

Sept. 7, 2012

Re: [Pharo-project] git support

by Goubier Thierry

Le 07/09/2012 13:37, Camillo Bruni a Ã©crit : > > On 2012-09-07, at 13:29, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Is using Git completely transparent so far? Or do I still need to manually write a "git push", "git pull" from the terminal? > > this is what is missing... we have the communication protocol for > downloading more or less ready, but we have to properly implement > the push. For the time being it works with an OSProcess call to `git push` That's transparent enough in my book. > but the goal is to have it completely transparent, otherwise I doubt > anybody will seriously use it from within pharo... OSProcess is a fine solution and it may be a tad easier to do it right. I would move to git if you get the transparent "OSProcess" working. Thierry >> Cheers, >> Alexandre >> >> >> On Sep 7, 2012, at 8:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> who will help? >>> >>> max and I, stimulated by ESUG, worked on the latest version of FS-Git to make it stable again. >>> we are very close to have a complete set of git tools written in pharo ready! >>> >>> missing >>> ======= >>> - a better mc integration >>> - a cypress compatible fileout format >>> - complete interaction with the git protocol >>> - a direct way to commit stuff >>> >>> as always my time is somewhat limited as well and we're the only two developers working on it... >>> >>> The current work is available here: >>> http://ss3.gemstone.com/ss/FSGit-Experimental.html >>> https://github.com/dalehenrich/FSGit > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Sept. 7, 2012

Re: [Pharo-project] git support

by Camillo Bruni

On 2012-09-07, at 13:29, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Is using Git completely transparent so far? Or do I still need to manually write a "git push", "git pull" from the terminal? this is what is missing... we have the communication protocol for downloading more or less ready, but we have to properly implement the push. For the time being it works with an OSProcess call to `git push` but the goal is to have it completely transparent, otherwise I doubt anybody will seriously use it from within pharo... > Cheers, > Alexandre > > > On Sep 7, 2012, at 8:15 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> who will help? >> >> max and I, stimulated by ESUG, worked on the latest version of FS-Git to make it stable again. >> we are very close to have a complete set of git tools written in pharo ready! >> >> missing >> ======= >> - a better mc integration >> - a cypress compatible fileout format >> - complete interaction with the git protocol >> - a direct way to commit stuff >> >> as always my time is somewhat limited as well and we're the only two developers working on it... >> >> The current work is available here: >> http://ss3.gemstone.com/ss/FSGit-Experimental.html >> https://github.com/dalehenrich/FSGit

Sept. 7, 2012