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

Re: [Pharo-project] about communication and collaboration

by phil＠highoctane.be

Old stuff of mine (10 years old oh my!) but still works: http://highoctane.be/articles/TeamManagementTeammeeting.html http://highoctane.be/articles/fog0000000032.html (Team Tracking) %s/CVS/Source Control/g %s/MSN/IM/g There is even a mention of the original SCRUM stuff: (1997!!!) http://jeffsutherland.org/scrum/scrum_pattern.html (For the fun & trivia, the fogxxxx name comes from FogCreek's CitiDesk CMS - Pharo is using FogBugz, looks like there is something in the fabric of the universe...) Phil 2013/3/12 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Tue, Mar 12, 2013 at 5:13 PM, stephane ducasse > <stephane.ducasse(a)free.fr> wrote: >> >> On Mar 12, 2013, at 4:48 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> >>> On Tue, Mar 12, 2013 at 4:02 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Dear Pharoers >>>> >>>> last january I visited another lab and I realised that the Pharo Team was not good at systematically telling what we were doing. >>>> I got quite frustrated by that situation, especially because we are working hard to build a better system. >>>> So we brainstormed when I came back and we want to apply the same ideas that what we do for our research team. >>>> >>>> For our research team every monday we get a simple mail that tell us to say to the others what we did and what we >>>> plan to do. Simple, easy. >>>> Then after people of the rmod team can discuss if they want more. >>> >>> It looks like quite an interesting idea in a research team. Do you a >>> have a description somewhere how it works ? >>> This is similar to a standup meeting ? >> >> we tried but a stand up meeting failed with us. >> So we just have a mail >> what you have done >> what you will do > > I would like to adopt such habits in my team, but standup meeting for > research team is not really convenient. > There is a paper where SCRUM is adapted to research team needs: > http://www.cs.umd.edu/~mwh/papers/score.pdf > > There is a business doing something like standup meeting by email here: > https://www.funscrum.com/ > Apparently all the answers are summarized automatically. > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ >

March 12, 2013

Re: [Pharo-project] Code review tools?

by Igor Stasenko

On 12 March 2013 13:05, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 12 March 2013 02:41, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 11 March 2013 22:06, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 11 March 2013 19:00, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 11 March 2013 19:06, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>>> On 11 March 2013 17:54, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>> pff... really people... i am thinking how to streamline our existing >>>>>> development process.. >>>>>> and instead i hear once again about git. >>>>> >>>>> Camillo needs to hit you around the head with a command line. You >>>>> haven't used it. You've heard several people who have used both >>>>> Monticello and git extensively say that git beats the crap out of >>>>> Monticello. Go and learn git properly. THEN come back and maybe we can >>>>> have a conversation. >>>>> >>>> I always using git from command line. And let me remind you it was me who >>>> created Cog mirrors on gitorious.. so, you shoot into the sky here. >>>> But i want more than that.. and why i happy to see that github proposes more >>>> on top, i do not really see how you can integrate that with usual >>>> workflow of smalltalk developer >>>> (means navigating/debugging living code in image). >>> >>> OK, fair enough. I had indeed forgotten about your gitorious work, and >>> in fact if I recall correctly you tried to pushed the VM folk into >>> moving from subversion to git. My apologies. >>> >>>>>> okay, lets throw away MC & stuff, migrate everything on file-based >>>>>> file-per-method git repository >>>>>> and then navigate diffs on github, and trying to find senders or >>>>>> implementors of selector using web browser . >>>>> >>>>> I do believe you ought to take a moment and go read the archives. >>>>> Also, I happen to nearly violently disagree with the file-per-method >>>>> approach, but that's an entirely different kettle of fish. >>>>> >>>>> But you know what, just forget it. It's not your problem, other people >>>>> are already solving the problem, and one day hopefully you'll forget >>>>> all about this while quietly your tools happily use git under the >>>>> hood, where you neither know nor care. >>>>> >>>> I actually don't care where files stored , in what format and what >>>> service it using. >>>> I want to make my life easier integrating those services with image, >>>> so i could, without switching >>>> contexts (like between image/web browser), do my work faster and more efficient. >>> >>> Yes, agreed. >>> >>> So if I can summarise, >>> >>> * git is not an answer for you because you don't care about the format >>> source is stored in. >>> * git is an answer for me because it immediately gives you a fantastic >>> user interface and hooks into just about everything. >>> * github is not an answer for you because it doesn't provide you with >>> any tools more advanced than a diff >>> * github is an answer for me because you can always implement your own >>> hooks for triggering CI, arbitrary code analysis, etc. Github's commit >>> API will let you give the green light or red light to any commit so >>> you can see at a glance how good a pull request is. >>> >> >> So, lets get back to the topic. Right now we have more or less same >> with MC + jenkins.. >> yes.. it may be ugly and inferior etc.. but if we compare human resources.. >> >> But see, the model right now is that to review the code, i must go to >> bug tracker/git >> (or if it is commit in some other project, go to that project repo) >> and manually load code from there.. >> and then after i loaded it into image, fun begins.. >> except that after review i have few choices: >> - send mail to author that his work sucks >> - say, code is fine and go back to web page, click here and there and >> mark it as OK.. >> >> now what i want is a tool which could help me to put a comments as i >> looking at code >> and then when i done, package that and upload where i want.. >> then other guy can load it into image and see my remarks.. >> >> yes, maybe it is too complicated/idealistic .. propose yours. >> >> >>> But of course there's nothing stopping one using github OR an-image >>> tools. (Or tools that produce custom images based on github commits >>> that run analyses and then persist somewhere so you can (a) see the >>> analyses immediately and (b) play around with the code. >>> >>> Mainly I think it's a mistake to reinvent tech _just because_ you >>> simply must work in an image. That's the core behind my moaning. (And >>> yes, I am working on addressing these issues, so I'm not _just_ >>> moaning.) >>> >> >> Yes, please.. >> but i hope you agree with me, that reviewing smalltalk code on web >> page or in text/diff viewer is >> not something you can do, if you wanna do it for real, not just >> looking for typos :) >> For doing it for real, you need an image. > > I'll have to disagree with you there: reviewing diffs covers the most > important of my requirements, and github's webhooks covers the rest: > * does this pull request pass all its tests? > * is the test coverage sufficient? > * when it gets merged in, will the new master pass all its tests? > > I _do_ agree that for more advanced review - tinkering around with the > pull request - you'd need to be inside an image, running the code. But > I don't see how you can't have that with github. Your webhook calls > out to the CI, which constructs you a clean image with the pull > request merged in, and you download that image. You could set up your > browser to run that artifact directly off the link. So your workflow > would be: > > * get a mail that someone's opened a pull request > * open up your browser > * check the commit status of the pull request - if it's red, reject > the pull request. > * assuming the commit's green, click on the "details" link in the status > * you've set up that webhook to display the artifact itself in the > link, so that downloads the image and it starts running. > * you do whatever you need to do to verify the change. (Perhaps the > constructed image has a bunch of analysis/review tools preloaded.) > * you accept or reject the pull request in your browser > > But this presupposes that you've spent some time on > * getting a git backend set up (not hard: filetree and gitocello > already do this; it boils down to new McStReader/Writers) > * figuring out how exactly you construct an image from the sources. > > That second step's the harder of the two, but I'd have thought not > _too_ hard given the work on bootstrapping Pharo? > Well, Frank, what i initially proposed is to do something on top of what we currently have. My idea is that code review tools in image can be used universally for any code no matter where it goes from. But you diverting discussion whether we should drop everything we did so far (jenkins setup, issue tracker etc), the whole infrastructure ecosystem we built over last few years and migrate to github... That will not happen, because there's a lot of inertia and amount of work to do. So, we should think how we can introduce things gradually and then at one day we will get there.. > frank > -- Best regards, Igor Stasenko.

March 12, 2013

Re: [Pharo-project] about communication and collaboration

by Serge Stinckwich

On Tue, Mar 12, 2013 at 5:13 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Mar 12, 2013, at 4:48 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > >> On Tue, Mar 12, 2013 at 4:02 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Dear Pharoers >>> >>> last january I visited another lab and I realised that the Pharo Team was not good at systematically telling what we were doing. >>> I got quite frustrated by that situation, especially because we are working hard to build a better system. >>> So we brainstormed when I came back and we want to apply the same ideas that what we do for our research team. >>> >>> For our research team every monday we get a simple mail that tell us to say to the others what we did and what we >>> plan to do. Simple, easy. >>> Then after people of the rmod team can discuss if they want more. >> >> It looks like quite an interesting idea in a research team. Do you a >> have a description somewhere how it works ? >> This is similar to a standup meeting ? > > we tried but a stand up meeting failed with us. > So we just have a mail > what you have done > what you will do I would like to adopt such habits in my team, but standup meeting for research team is not really convenient. There is a paper where SCRUM is adapted to research team needs: http://www.cs.umd.edu/~mwh/papers/score.pdf There is a business doing something like standup meeting by email here: https://www.funscrum.com/ Apparently all the answers are summarized automatically. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://doesnotunderstand.org/

March 12, 2013

Re: [Pharo-project] beta 1.4 documentation online

by Camillo Bruni

how I hate the options of the VM |( no --help, -help exits unsuccessful .... grml grml grml On 2013-03-12, at 17:20, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > And it is not even true > > <imageName> defaults to `Squeak.image'. > > as I get a file dialog when such an image is in the folder. (Duly > created with the save command) > > Phil > > 2013/3/12 Camillo Bruni <camillobruni(a)gmail.com>: >> >> On 2013-03-12, at 16:51, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> These are the standard installed handlers: >>> >>> $ ../vm.sh Pharo.image --list >>> Currently installed Command Line Handlers: >>> st Loads and executes .st source files >>> Fuel Loads fuel files >>> config Install and inspect Metacello Configurations from the command line >>> save Rename the image and changes file >>> test A command line test runner >>> update Load updates >>> printVersion Print image version >>> eval Directly evaluates passed in one line scripts >>> >>> for each of them you can do --help >>> >>> $ ../vm.sh Pharo.image save --help >>> Usage: save <imageBaseName> [--delete-old] >>> <imageName> a base name for the image >>> --delete-old remove the old image and changes file >>> >>> Documentation: >>> Saves the image and changes file under a new name. >>> >>> Examples: >>> # create a 'bar.image' and 'foo.changes' >>> $PHAROVM Foo.image saveAs bar >>> # create the same file as in the previous example but delete Foo.image and Foo.changes >>> $PHAROVM Foo.image saveAs bar --delete-old >>> >>> Sven >> >> ups, typos, typos: saveAs => save :/ >> I'll open an issue >> >> >>> On 12 Mar 2013, at 16:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> That already exists no ? >>>> >>>> $ ./vm.sh Pharo.image save Foo >>>> >>>> will do a 'Save As..' to Foo.[image|changes] >>>> >>>> On 12 Mar 2013, at 16:45, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> BTW, an interesting additional ./vm.sh command would be: >>>>> >>>>> $./vm.sh clone Pharo WebDocExperiment >>>>> >>>>> which would do a copy of Pharo.image and Pharo.changes to the >>>>> WebDoc.image and WebDoc.changes >>>>> >>>>> Phil >>>>> 2013/3/12 Martin Dias <tinchodias(a)gmail.com>: >>>>>> impressive!! >>>>>> >>>>>> On Tue, Mar 12, 2013 at 3:06 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>>>>> http://pharo.gforge.inria.fr/doc/1.4/doc/package/undefined >>>>>>> >>>>>>> RSArrayNode. >>>>>>> >>>>>>> 2013/3/12 Camillo Bruni <camillobruni(a)gmail.com>: >>>>>>>> >>>>>>>> On 2013-03-12, at 14:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> On Tue, Mar 12, 2013 at 2:18 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >>>>>>>>> >>>>>>>>>> finally, after the 100th attempt I managed to export the documentation on >>>>>>>>>> 1.4 >>>>>>>>>> >>>>>>>>>> http://pharo.gforge.inria.fr/doc/1.4 >>>>>>>>>> >>>>>>>>>> this weekend I will tackle 2.0 :) and of course, it still needs some love! >>>>>>>>>> >>>>>>>>>> >>>>>>>>> - How can I export it myself too? >>>>>>>> >>>>>>>> currently work in progress, but there is a configuration for it: >>>>>>>> >>>>>>>> Gofer new >>>>>>>> url: 'http://smalltalkhub.com/mc/dh83/webdoc/main' >>>>>>>> configurationOf: 'WebDoc'; >>>>>>>> loadDevelopment. >>>>>>>> >>>>>>>> And I think you have to manually start up a seaside adapter, once that is done: >>>>>>>> >>>>>>>> http://localhost:8080/doc >>>>>>>> >>>>>>>> should do the trick. >>>>>>>> >>>>>>>> >>>>>>>>> - We should report issues about it in the foogzbuz (or whatever it is >>>>>>>>> called I cannot reproduce yet :P). >>>>>>>> >>>>>>>> yes, maybe let's wait until next weekend :) since it doesn't run under >>>>>>>> 2.0 yet :P. I won't work on during the day :P that is reserved for Guido and >>>>>>>> the paper... >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >

March 12, 2013

Re: [Pharo-project] WhatsUp from: 2013-03-11 until: 2013-03-24

by phil＠highoctane.be

Yeah, that's what you get by being your own boss :-) Too bad I need to put bread on the table. Hopefully this will be done using Pharo technology within a year or two from now. Phil 2013/3/12 stephane ducasse <stephane.ducasse(a)free.fr>: > sounds like a cool set of issues :) > > On Mar 12, 2013, at 5:04 PM, phil(a)highoctane.be wrote: > >> ### Here's what I've been up to since the last WhatsUp: >> >> * Trying out new image and messing around, reporting bugs in the process >> * Reporting issues with the iOS VM build >> * Getting the iOS VM to recognize a bluetooth keyboard >> * Getting the VM to build for debian 6 amd64 >> >> ### What's next, until 2013-03-24 (*): >> >> * Finishing up keyboard mapping for iOS VM >> * Understanding how to have amber working with Pharo through AidaWeb >> * Trying out new stuff coming my way >> * Getting the InterpreterSimulator running into the image >> >> Phil >> > >

March 12, 2013

Re: [Pharo-project] Latest pharo issue with Eliot's latest Cog

by Esteban Lorenzano

is GLMMorphicExamplesTest>>#testSmoke On Mar 12, 2013, at 5:55 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On Mar 12, 2013, at 5:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> I understand and encourage the streamlining of efforts. And I have no problem with dealing with the bumps of living on the latest version, be it the VM or the image. >> >> But, please consider the point of view of the one that offers the feedback. Right now, it sounds as if you are shooting down an unreasonable request from Stephan, but in this case, Esteban suggested that we should use the Cog VM instead of the Pharo VM to develop Moose, given that the Pharo VM is basically broken for us. >> >> So, Stephan did exactly that: he used the Cog VM. He reported that the tests do not crash the VM, which I think should be a relevant input, and he also reported other problems while running on the Cog VM. These errors indeed seem to be related to FileSystem, and this just shows that using the Cog VM as a temporary solution does not work. So, we have to focus on the Pharo VM. > > > doru do you have an idea of the tests that crash the vm? > >> >> And now, I am back to the original question: What other tests or experiments would you like us to do to help with identifying the problem? >> >> Cheers, >> Doru >> >> >> On Tue, Mar 12, 2013 at 4:53 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> FileDialogs apparently make use of the new FileSystem values, so yes, >> the update-our-VM-warning is there for a good reason! >> >> On 2013-03-12, at 16:47, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> > The problem is not just with the MOOSE image, >> > Pharo 20598 and Cog.app 2071 doesn't allow a >> > file dialog to be opened. >> > >> > FileDialogWindow new open >> > >> > Stephan >> > >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >

March 12, 2013

Re: [Pharo-project] WhatsUp from: 2013-03-11 until: 2013-03-24

by stephane ducasse

sounds like a cool set of issues :) On Mar 12, 2013, at 5:04 PM, phil(a)highoctane.be wrote: > ### Here's what I've been up to since the last WhatsUp: > > * Trying out new image and messing around, reporting bugs in the process > * Reporting issues with the iOS VM build > * Getting the iOS VM to recognize a bluetooth keyboard > * Getting the VM to build for debian 6 amd64 > > ### What's next, until 2013-03-24 (*): > > * Finishing up keyboard mapping for iOS VM > * Understanding how to have amber working with Pharo through AidaWeb > * Trying out new stuff coming my way > * Getting the InterpreterSimulator running into the image > > Phil >

March 12, 2013

Re: [Pharo-project] Latest pharo issue with Eliot's latest Cog

by stephane ducasse

On Mar 12, 2013, at 5:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I understand and encourage the streamlining of efforts. And I have no problem with dealing with the bumps of living on the latest version, be it the VM or the image. > > But, please consider the point of view of the one that offers the feedback. Right now, it sounds as if you are shooting down an unreasonable request from Stephan, but in this case, Esteban suggested that we should use the Cog VM instead of the Pharo VM to develop Moose, given that the Pharo VM is basically broken for us. > > So, Stephan did exactly that: he used the Cog VM. He reported that the tests do not crash the VM, which I think should be a relevant input, and he also reported other problems while running on the Cog VM. These errors indeed seem to be related to FileSystem, and this just shows that using the Cog VM as a temporary solution does not work. So, we have to focus on the Pharo VM. doru do you have an idea of the tests that crash the vm? > > And now, I am back to the original question: What other tests or experiments would you like us to do to help with identifying the problem? > > Cheers, > Doru > > > On Tue, Mar 12, 2013 at 4:53 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > FileDialogs apparently make use of the new FileSystem values, so yes, > the update-our-VM-warning is there for a good reason! > > On 2013-03-12, at 16:47, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > The problem is not just with the MOOSE image, > > Pharo 20598 and Cog.app 2071 doesn't allow a > > file dialog to be opened. > > > > FileDialogWindow new open > > > > Stephan > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

March 12, 2013

Re: [Pharo-project] WhatsUp from: 2013-03-11 until: 2013-03-24

by Benjamin

On Mar 12, 2013, at 4:53 PM, seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: - Penelope website - Finish the issues migration - FTP Server done (for a lecture ^^) - Helios pair-programming sessions with Nico > ### What's next, until 2013-03-24 (*): - more Helios pair-programming - REST api for the FTP Server (for the same lecture) - a bit of days off after Pharo release > > (*) we'll be expecting results by then ;) > Ben

March 12, 2013

Re: [Pharo-project] Latest pharo issue with Eliot's latest Cog

by Tudor Girba

Great. We will try that. Thanks, Doru On Tue, Mar 12, 2013 at 5:37 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Well.. looks like there is a misunderstanding here. > I suggested use a CogVM. yes, but one of our builds, not Eliot's. > > PharoVM was born two weeks ago. Before that, we were producing CogVM and > NBCogVM regularly. I suggested to use one of those, IÂ´m sorry if it was not > clear. > The right VMs can be found here: > http://pharo.gforge.inria.fr/ci/vm/nbcog/ > > (yes, the whole vm thing is a mess, we will clean it eventually, but it > will take some time...) > > Esteban > > > On Mar 12, 2013, at 5:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I understand and encourage the streamlining of efforts. And I have no > problem with dealing with the bumps of living on the latest version, be it > the VM or the image. > > But, please consider the point of view of the one that offers the > feedback. Right now, it sounds as if you are shooting down an unreasonable > request from Stephan, but in this case, Esteban suggested that we should > use the Cog VM instead of the Pharo VM to develop Moose, given that the > Pharo VM is basically broken for us. > > So, Stephan did exactly that: he used the Cog VM. He reported that the > tests do not crash the VM, which I think should be a relevant input, and he > also reported other problems while running on the Cog VM. These errors > indeed seem to be related to FileSystem, and this just shows that using the > Cog VM as a temporary solution does not work. So, we have to focus on the > Pharo VM. > > And now, I am back to the original question: What other tests or > experiments would you like us to do to help with identifying the problem? > > Cheers, > Doru > > > On Tue, Mar 12, 2013 at 4:53 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >> FileDialogs apparently make use of the new FileSystem values, so yes, >> the update-our-VM-warning is there for a good reason! >> >> On 2013-03-12, at 16:47, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> > The problem is not just with the MOOSE image, >> > Pharo 20598 and Cog.app 2071 doesn't allow a >> > file dialog to be opened. >> > >> > FileDialogWindow new open >> > >> > Stephan >> > >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

March 12, 2013