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

[Pharo-project] World menu > System > Switch User : What's that?

by phil＠highoctane.be

I was wondering what this was for? Permissions? Huh? Thanks for shedding some light on that! Phil

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Frank Shearar

On 12 March 2013 18:55, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Thanks a lot all to all of you for that valuable information. > > BTW, there is no pure PharoInterpreterVM available anywhere. And the > InterpeterVM Frank mentioned is only available in Unix, not in OSX. > (this for learning with the InterpreterSimulator in VMMaker packages) Mm, kinda sorta. In the squeak-ci repo there's a builtasticMac.sh which builds the Interpreter on OSX [1]. But it's not the "proper" OSX VM a la Carbon or Cocoa; it's the Unix Interpreter VM built on a Mac. frank [1] https://github.com/frankshearar/squeak-ci/blob/master/functions.sh#L43 > From a personal POV, I like the ability to build as in the CMake > process and the PharoVM layout better; more logical to me. Getting > CMake behave is indeed no small feat. > > But the fact that the VMMaker simulators don't work with the Pharo > image is annoying. > > Any further clues? > > Phil > > 2013/3/12 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >>> >>> We use an automated building method that tries to be exactly the same in >>> each platform. We decided not to create bundles but dylibs because bundles >>> are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >>> Our process builds the vm, the plugins and the third party libraries as an >>> all-in-one. Eliot builds are hand made, and when there is a process (like >>> the autotool for unix builds), they are platform-specific. >> >> >> That mine are hand-builkt is a straw man. They're not. I kick off the >> builds by hand but everything is scripted and reproducible, and included in >> the generated source. I don't (yet) have access to Jenkins for all three >> platforms. But the VMs at Cadence are now all built via Jenkins (thanks to >> Bob Westergaard). What's different is a fork. >> >> 1. Cog includes the set of plugins that came from Qwaq/Teleplace plus the >> plugin needed to develop the VM (the x86 simulator BochsIA32Plugin). Pharo >> uses the set of plugins it has chosen (several of the same plugins are >> internal to the Cog VM, e.g. UUIDPlugin is internal in Cog). >> >> 2. Pharo uses CMake driven from Smalltalk; I'm too lazy to move, so automake >> is used (one in a blue moon) on linux, and hand-crafted makefiles on Mac and >> Windows (that don't change much). The Pharo way is better (although I find >> CMake as incomprehensible and arbitrary as automake), but both Cog and Pharo >> have predictable C make systems. >> >> 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons and >> c) new FileSystem primitives. >> a) is cool, but I don't like the x86 specificity. I want a cross-platform >> FFI, so I'm not excited enough to include NB in my port. >> b) is useful (I fixed the implementation of ephemerons for VisualWorks done >> by someone else a while back, and I understand them well), but I don't like >> Igor's implementation. IMO the ephemeronness of an object needs to be >> reflected in its format field (the 4 bit type field in every object), not >> found by indirecting through the class, which is hairy in the current GC and >> slow. I've proposed an alternative and Igor is I think in agreement, but we >> have to find the time to implement it. >> c) I have to find time to port. Its a no-brainer. >> >>> >>> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >>> >>> Esteban >>> >>> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> >>> wrote: >>> >>> > Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >>> > >>> > And worth some explanations :-) Why is it that way? >>> > >>> > Phil >>> > >>> > 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >>> >>> It would be good to have a parallel job, but the problem is that you >>> >>> will >>> >>> get a message saying that the VM is too old for the Pharo 2.0 image. >>> >> >>> >> I started the latest MOOSE image on Eliots latest VM on mac. >>> >> It still has the 'old vm' warning. >>> >> Adding a monticello repository (directory) doesn't work. >>> >> Tests are still running >>> >> >>> >> Stephan >>> >> >>> >> >>> > <2013-03-12_10-43-37.png> >>> >>> >> >> >> >> -- >> best, >> Eliot >

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Esteban Lorenzano

On Mar 12, 2013, at 7:44 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > We use an automated building method that tries to be exactly the same in each platform. We decided not to create bundles but dylibs because bundles are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. > Our process builds the vm, the plugins and the third party libraries as an all-in-one. Eliot builds are hand made, and when there is a process (like the autotool for unix builds), they are platform-specific. > > That mine are hand-builkt is a straw man. They're not. I kick off the builds by hand but everything is scripted and reproducible, and included in the generated source. I don't (yet) have access to Jenkins for all three platforms. But the VMs at Cadence are now all built via Jenkins (thanks to Bob Westergaard). What's different is a fork. my bad... I thought it was hand made, I'm sorry. Good to know that it isn't. > > 1. Cog includes the set of plugins that came from Qwaq/Teleplace plus the plugin needed to develop the VM (the x86 simulator BochsIA32Plugin). Pharo uses the set of plugins it has chosen (several of the same plugins are internal to the Cog VM, e.g. UUIDPlugin is internal in Cog). yes, as I said there is minimal difference between internal and external... just a a matter of taste if you want :) > > 2. Pharo uses CMake driven from Smalltalk; I'm too lazy to move, so automake is used (one in a blue moon) on linux, and hand-crafted makefiles on Mac and Windows (that don't change much). The Pharo way is better (although I find CMake as incomprehensible and arbitrary as automake), but both Cog and Pharo have predictable C make systems. yes, I agree that cmake is as incomprehensible as autoconf... a terrible pain when you need to touch them directly... thatÂ´s why we try to use the CMakeMaker package, who helps (but not completely) to make the task less painful. > > 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons and c) new FileSystem primitives. > a) is cool, but I don't like the x86 specificity. I want a cross-platform FFI, so I'm not excited enough to include NB in my port. > b) is useful (I fixed the implementation of ephemerons for VisualWorks done by someone else a while back, and I understand them well), but I don't like Igor's implementation. IMO the ephemeronness of an object needs to be reflected in its format field (the 4 bit type field in every object), not found by indirecting through the class, which is hairy in the current GC and slow. I've proposed an alternative and Igor is I think in agreement, but we have to find the time to implement it. > c) I have to find time to port. Its a no-brainer. I do not consider pharo a fork. I think is wrong to think on it like a separated development. We put some effort on top of your own effort to match other requirements (like NB, branding, allow some experiments, etc.), but in essence is the same cog... we just change the cover :) Most of the changes are now based on: NB, the Cocoa branch and some plugins not yet integrated... I hardly would consider that a fork (and we try not to fork in purpose: is dumb to divide the work of the few ppl who work on the vm level in our community). Pharo however has a different vision than other communities in some points, specifically about the plugins and its place: the plugins should be moved to inside the image as much as they can (that's why NB is so important for us). The idea is to allow the community to participate in maintaining the plugins and keep the vm programmers focused on... well, vm stuff :) Esteban > > > TL;DR: Is easier for us to build all the vm stuff in an unified way :) > > Esteban > > On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > > > Eliot's CogVM vs PharoVM on Mac application contents. Quite different. > > > > And worth some explanations :-) Why is it that way? > > > > Phil > > > > 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: > >>> It would be good to have a parallel job, but the problem is that you will > >>> get a message saying that the VM is too old for the Pharo 2.0 image. > >> > >> I started the latest MOOSE image on Eliots latest VM on mac. > >> It still has the 'old vm' warning. > >> Adding a monticello repository (directory) doesn't work. > >> Tests are still running > >> > >> Stephan > >> > >> > > <2013-03-12_10-43-37.png> > > > > > > -- > best, > Eliot

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by phil＠highoctane.be

Thanks a lot all to all of you for that valuable information. BTW, there is no pure PharoInterpreterVM available anywhere. And the InterpeterVM Frank mentioned is only available in Unix, not in OSX. (this for learning with the InterpreterSimulator in VMMaker packages) >From a personal POV, I like the ability to build as in the CMake process and the PharoVM layout better; more logical to me. Getting CMake behave is indeed no small feat. But the fact that the VMMaker simulators don't work with the Pharo image is annoying. Any further clues? Phil 2013/3/12 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: >> >> We use an automated building method that tries to be exactly the same in >> each platform. We decided not to create bundles but dylibs because bundles >> are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. >> Our process builds the vm, the plugins and the third party libraries as an >> all-in-one. Eliot builds are hand made, and when there is a process (like >> the autotool for unix builds), they are platform-specific. > > > That mine are hand-builkt is a straw man. They're not. I kick off the > builds by hand but everything is scripted and reproducible, and included in > the generated source. I don't (yet) have access to Jenkins for all three > platforms. But the VMs at Cadence are now all built via Jenkins (thanks to > Bob Westergaard). What's different is a fork. > > 1. Cog includes the set of plugins that came from Qwaq/Teleplace plus the > plugin needed to develop the VM (the x86 simulator BochsIA32Plugin). Pharo > uses the set of plugins it has chosen (several of the same plugins are > internal to the Cog VM, e.g. UUIDPlugin is internal in Cog). > > 2. Pharo uses CMake driven from Smalltalk; I'm too lazy to move, so automake > is used (one in a blue moon) on linux, and hand-crafted makefiles on Mac and > Windows (that don't change much). The Pharo way is better (although I find > CMake as incomprehensible and arbitrary as automake), but both Cog and Pharo > have predictable C make systems. > > 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons and > c) new FileSystem primitives. > a) is cool, but I don't like the x86 specificity. I want a cross-platform > FFI, so I'm not excited enough to include NB in my port. > b) is useful (I fixed the implementation of ephemerons for VisualWorks done > by someone else a while back, and I understand them well), but I don't like > Igor's implementation. IMO the ephemeronness of an object needs to be > reflected in its format field (the 4 bit type field in every object), not > found by indirecting through the class, which is hairy in the current GC and > slow. I've proposed an alternative and Igor is I think in agreement, but we > have to find the time to implement it. > c) I have to find time to port. Its a no-brainer. > >> >> TL;DR: Is easier for us to build all the vm stuff in an unified way :) >> >> Esteban >> >> On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> >> wrote: >> >> > Eliot's CogVM vs PharoVM on Mac application contents. Quite different. >> > >> > And worth some explanations :-) Why is it that way? >> > >> > Phil >> > >> > 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: >> >>> It would be good to have a parallel job, but the problem is that you >> >>> will >> >>> get a message saying that the VM is too old for the Pharo 2.0 image. >> >> >> >> I started the latest MOOSE image on Eliots latest VM on mac. >> >> It still has the 'old vm' warning. >> >> Adding a monticello repository (directory) doesn't work. >> >> Tests are still running >> >> >> >> Stephan >> >> >> >> >> > <2013-03-12_10-43-37.png> >> >> > > > > -- > best, > Eliot

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Eliot Miranda

On Tue, Mar 12, 2013 at 2:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > We use an automated building method that tries to be exactly the same in > each platform. We decided not to create bundles but dylibs because bundles > are mac-specific stuff and .dylibs same (but for mac) as .so and .dll. > Our process builds the vm, the plugins and the third party libraries as an > all-in-one. Eliot builds are hand made, and when there is a process (like > the autotool for unix builds), they are platform-specific. > That mine are hand-builkt is a straw man. They're not. I kick off the builds by hand but everything is scripted and reproducible, and included in the generated source. I don't (yet) have access to Jenkins for all three platforms. But the VMs at Cadence are now all built via Jenkins (thanks to Bob Westergaard). What's different is a fork. 1. Cog includes the set of plugins that came from Qwaq/Teleplace plus the plugin needed to develop the VM (the x86 simulator BochsIA32Plugin). Pharo uses the set of plugins it has chosen (several of the same plugins are internal to the Cog VM, e.g. UUIDPlugin is internal in Cog). 2. Pharo uses CMake driven from Smalltalk; I'm too lazy to move, so automake is used (one in a blue moon) on linux, and hand-crafted makefiles on Mac and Windows (that don't change much). The Pharo way is better (although I find CMake as incomprehensible and arbitrary as automake), but both Cog and Pharo have predictable C make systems. 3. Pharo has forked the VM to include a) NativeBoost and b) ephemerons and c) new FileSystem primitives. a) is cool, but I don't like the x86 specificity. I want a cross-platform FFI, so I'm not excited enough to include NB in my port. b) is useful (I fixed the implementation of ephemerons for VisualWorks done by someone else a while back, and I understand them well), but I don't like Igor's implementation. IMO the ephemeronness of an object needs to be reflected in its format field (the 4 bit type field in every object), not found by indirecting through the class, which is hairy in the current GC and slow. I've proposed an alternative and Igor is I think in agreement, but we have to find the time to implement it. c) I have to find time to port. Its a no-brainer. > TL;DR: Is easier for us to build all the vm stuff in an unified way :) > > Esteban > > On Mar 12, 2013, at 10:49 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> > wrote: > > > Eliot's CogVM vs PharoVM on Mac application contents. Quite different. > > > > And worth some explanations :-) Why is it that way? > > > > Phil > > > > 2013/3/12 Stephan Eggermont <stephan(a)stack.nl>: > >>> It would be good to have a parallel job, but the problem is that you > will > >>> get a message saying that the VM is too old for the Pharo 2.0 image. > >> > >> I started the latest MOOSE image on Eliots latest VM on mac. > >> It still has the 'old vm' warning. > >> Adding a monticello repository (directory) doesn't work. > >> Tests are still running > >> > >> Stephan > >> > >> > > <2013-03-12_10-43-37.png> > > > -- best, Eliot

March 12, 2013

Re: [Pharo-project] beta 1.4 documentation online

by Mariano Martinez Peck

Why don't we add a link in the Pharo website with such an online help? It would be nice if this is indexable by Google. Thanks Cami!!! Nice job On Tue, Mar 12, 2013 at 2:00 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > 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... > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > > > > -- Mariano http://marianopeck.wordpress.com

March 12, 2013

Re: [Pharo-project] beta 1.4 documentation online

by Igor Stasenko

just found that no matter which package i selected, if i click on a first class in list, it always goes to http://pharo.gforge.inria.fr/doc/1.4/doc/package/undefined (however when you hover over the link it shows different url) looks like some js trouble On 12 March 2013 14:18, 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! > -- Best regards, Igor Stasenko.

March 12, 2013

Re: [Pharo-project] where to report vm crashes? (while running Moose tests)

by Igor Stasenko

On 12 March 2013 10:49, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Eliot's CogVM vs PharoVM on Mac application contents. Quite different. > > And worth some explanations :-) Why is it that way? > There was a discussion about that in dev list, and decision was made. First thing, putting external modules in "Resources" is non-common for Apple apps. Most of them putting extras in same directory where executable is.. because those bundles are platform-specific. As for using dylibs instead of bundles.. if external module is just a single binary file (as in case with plugins), why bundling it? i would understand if it would contain a .h files, and some other resources, then it would make sense. -- Best regards, Igor Stasenko.

March 12, 2013

Re: [Pharo-project] the PharoTeam right now

by Igor Stasenko

On 12 March 2013 12:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > http://www.pbase.com/giancarlob/image/91276919 > or kind of :) > > Meteo France called the 25 cm of snow falling on us a "remarkable" event. > > the last bite of winter is bitting us hard :) > Stef > > hehe... dunno.. in place where i lived, thing like that was happening quite often (not every winter but quite regularily). -- Best regards, Igor Stasenko.

March 12, 2013

Re: [Pharo-project] Code review tools?

by Frank Shearar

On 12 March 2013 17:46, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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.. On the one hand you need these fancy review/merge tools... which github _largely_ gives you, but you'd have to write some code to use git properly. (*) Or you can write the fancy review/merge tools yourself. You're saying "wow, it really sucks the way we have to work" and I'm saying "wow, it's so easy to review/merge code on github" and you're saying "gosh, we have to throw everything away!". No, you don't. Keep your CI; it's better by far than Travis's, and you just write a webhook for github to trigger builds. Keep your issue tracker; it's better than github's. Now does github give you super static analysis tools? Does it do k-CFA to check your types are what you think they are? No. It _does_ give you a really slick code review process into which you can plug anything you want, and you can record the outcome of all those analyses in a simple red/green commit status on every commit in the pull request. So, to take another tack, what kind of tools do you find you have to have to conduct a proper review? I can imagine a bunch of automated tests ("did coverage decrease since the last run?" for instance), but those are uninteresting - if they're automated you shouldn't be doing them, but merely reviewing their output. frank (*) I don't think this is very hard: I knocked up an InstallerGitHub that pulls source from an arbitrary commit (so tag, branch name, commit id) from a github repository in chunk format (need to support filetree still, which is why I've not released anything yet). So I can imagine a webhook that when pinged will take a Squeak trunk, run Installer github user: 'frankshearar repository: 'Zippers'; install: 'ConfigurationOfZippers'. (Smalltalk at: #ConfigurationOfZippers) load. "Run the tests, and ping back to github the commit status" frank

March 12, 2013