- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Integration process in presence of "external" project

by stepharo

Le 22/4/15 13:21, Esteban Lorenzano a Ã©crit : > exactly. > what we need in the long term is a complete better integration process. > I dream to have a git pharo project with submodules and pull requests. > > Slowly the tools are coming, but this will take time to implement. > In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. > Even if they look not easy because we are still building it, or too used to previous ways of doing it. This is ok for me but I will not work on this condition. I will just frustrate too much. Just waiting that somebody somewhere is integrating a stupid change so that I can work. Because there are moments where I can work and other not. I will accomodate about this and work on other projects than Pharo. Stef

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by stepharo

Le 22/4/15 13:01, Guillermo Polito a Ã©crit : > Well, I agree with Esteban and Thierry in the fact that making our > lives easier to manage now by pushing changes into the Pharo/main > branch will make things harder in the long run. Yes but you see when you clean the architecture and the dependencies then after you can change not before. At least I'm not Toyota (if you know the story). My time is too limited. > > I think we can see this as a case of two dependent configurations > > ConfigurationOfPharo (which does not exist but as the ad-hoc list of > packages in Pharo/main) > > ConfigurationOfRubric => depends on ConfigurationOfPharo > > Stef, I'd manage it like this: > > - push the change we have into rubric > - open an issue number X asking for the integration of rubric with > that feature > - open an issue Y that depends on X with the other slice of changes > > And here the main problem that we will have is that if we do not > integrate quickly these fixes, then slices can age and become not valid. This is ok for me so I will not work on anything during the summer. Because when people are on vacation what do we do? Busy polling? Play magic? > > Alternatively, we can do it in several steps, avoiding the dependency: > > - push the change into rubric > - push the part of the change into pharo that does not break the > current version of rubric (avoid the renames/removals of methods) > - when both are integrated we do the last step that integrates the > last set of changes And die in deadlock? > El miÃ©., 22 de abr. de 2015 a la(s) 11:15 a. m., Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> escribiÃ³: > > Le 22/04/2015 10:21, Andrei Chis a Ã©crit : > > > > > > On Wed, Apr 22, 2015 at 9:02 AM, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> wrote: > > > > in fact I just checked and Versioner already does that: > right button > > on monticello over a configuration gives you a: âcreate > > development/release versionâ. > > So only thing we need is to use the tools we already created :) > > > > > > But this only works for releasing simple configurations that do not > > depend on other configurations. > > This would work for rubric, for example, but not for other > > configurations we have in gtools. > > I believe GTTools is certainly a poster case for trying to make that > process simpler. > > I would really be interested to see how a combination of simpler > configurations, baselines, tags and branches would look. A kind of > hierarchical modeling where you only have configurations at the > moment. > > Thierry > > > > > > Cheers, > > Andrei > > > > > > > On 22 Apr 2015, at 08:50, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> > wrote: > > > > > > and btwâ¦ of course I agree repositories need to be added, and > > configurations kept in image. > > > > > > cheers, > > > Esteban > > > > > >> On 22 Apr 2015, at 08:34, Esteban Lorenzano > <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > > <mailto:estebanlm@gmail.com <mailto:estebanlm@gmail.com>>> > wrote: > > >> > > >> I disagree with your proposal. > > >> It will be a mess, nobody will merge (because there will > be no > > point on doing it) and we will not move out from a > monolithic system. > > >> What I propose is not an invention, is how big projects > workâ¦ > > what you have to take into account is that any project under the > > Pharo umbrella does not have an owner, but a maintainer. > That means > > if Alan is on vacation or he does not has the time to do the new > > configuration, anyone can doit. > > >> > > >> Yes, it can look slow, but that is because you are too > used to > > the old workflow, and because right now system is not modular. > > >> The method I propose will enhance modularity (while the > older > > will, at least, not help), which means with time, changes > will be > > applied just in one module and not along the full system > like now. > > >> > > >> Of course with proper tools this will be faster, but I > very much > > prefer people telling me âI need thisâ (thatâs why I did the > > integrator app, and modified the monkey to take and validate > > configurations), and we do it, that we abandon our pursuit of > > modularity because is uncomfortable at the beginning. > > >> > > >> We can modify also monticello or versioner (better > monticello > > because everything will be closer, but using versioner API) > to do a > > âsave new versionâ which would be more or less the same as a > slice, > > but for a configuration, and it will: > > >> > > >> - save the packages associated to the configuration > > >> - create a new version > > >> - save the new configuration > > >> > > >> this will not be to much work (I think I can have it in > a couple > > of days), it will help the process (because eventually > everything > > should be managed through configurations (or PPM > configurations), > > and it will allow us to keep a process that is better and > validated.. > > >> > > >> TL;DR: Better enhance the tools than drop the process. > > >> > > >> Esteban > > >> > > >>> On 22 Apr 2015, at 07:47, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr> > > <mailto:stepharo@free.fr <mailto:stepharo@free.fr>>> wrote: > > >>> > > >>> Esteban > > >>> I was thinking about the following this night. > > >>> > > >>> While I understand that we want configuration only it > will slow > > us down like hell. > > >>> > > >>> Example > > >>> with guille we wanted to fix a problem (I do not > remember which > > one) > > >>> we need a change to be done in rubric so we will have to > > publish the change in rubric repo > > >>> - (find it and add it) so the rubric repo should be > there before > > >>> - then one guy of rubric should have a look > > >>> - then merge > > >>> - then publish an issue with a configuration > > >>> - then only then we can work > > >>> => result why do we need sync for me and guille to > continue to > > work??? > > >>> => what if Alain in on vacation? > > >>> we stop working? > > >>> => Remember: We did Pharo especially because people in > squeak > > did not want that we change > > >>> packages. > > >>> > > >>> Alternate process > > >>> - we do a fix we publish it in Pharo and yes this touches > > Rubric and > > >>> - we integrate it in Pharo head > > >>> - then the guy from rubric merge in their trunk when > they want. > > >>> it should be part of the their process to merge always > > with pharo trunk > > >>> - At that point they can report a problem > > >>> - then they produce at their speed a new configuration > > >>> - then we integrate when ready their change > > >>> > > >>> > > >>> Stef > > >>> > > >>> > > >> > > > > > > > > > > >

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by stepharo

> in fact I just checked and Versioner already does that: right button on monticello over a configuration gives you a: âcreate development/release versionâ. > So only thing we need is to use the tools we already created :) Well did you try the configurations that other people created with versionner? I will not fix them. Stef > > >> On 22 Apr 2015, at 08:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> and btwâ¦ of course I agree repositories need to be added, and configurations kept in image. >> >> cheers, >> Esteban >> >>> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> I disagree with your proposal. >>> It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. >>> What I propose is not an invention, is how big projects workâ¦ what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit. >>> >>> Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. >>> The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. >>> >>> Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning. >>> >>> We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will: >>> >>> - save the packages associated to the configuration >>> - create a new version >>> - save the new configuration >>> >>> this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated.. >>> >>> TL;DR: Better enhance the tools than drop the process. >>> >>> Esteban >>> >>>> On 22 Apr 2015, at 07:47, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Esteban >>>> I was thinking about the following this night. >>>> >>>> While I understand that we want configuration only it will slow us down like hell. >>>> >>>> Example >>>> with guille we wanted to fix a problem (I do not remember which one) >>>> we need a change to be done in rubric so we will have to publish the change in rubric repo >>>> - (find it and add it) so the rubric repo should be there before >>>> - then one guy of rubric should have a look >>>> - then merge >>>> - then publish an issue with a configuration >>>> - then only then we can work >>>> => result why do we need sync for me and guille to continue to work??? >>>> => what if Alain in on vacation? >>>> we stop working? >>>> => Remember: We did Pharo especially because people in squeak did not want that we change >>>> packages. >>>> >>>> Alternate process >>>> - we do a fix we publish it in Pharo and yes this touches Rubric and >>>> - we integrate it in Pharo head >>>> - then the guy from rubric merge in their trunk when they want. >>>> it should be part of the their process to merge always with pharo trunk >>>> - At that point they can report a problem >>>> - then they produce at their speed a new configuration >>>> - then we integrate when ready their change >>>> >>>> >>>> Stef >>>> >>>> > >

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by stepharo

> and btwâ¦ of course I agree repositories need to be added, and configurations kept in image. So what will happen when I publish a configuration with new package in the repo of XXX where XXX is under dev or under a more recent version. They will have to merge. Because I will only publish to be able to load the code I changed into just the next version of Pharo so that I can continue to work on the other parts of the changes. Stef > > cheers, > Esteban > >> On 22 Apr 2015, at 08:34, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> I disagree with your proposal. >> It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. >> What I propose is not an invention, is how big projects workâ¦ what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit. >> >> Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. >> The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. >> >> Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning. >> >> We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will: >> >> - save the packages associated to the configuration >> - create a new version >> - save the new configuration >> >> this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated.. >> >> TL;DR: Better enhance the tools than drop the process. >> >> Esteban >> >>> On 22 Apr 2015, at 07:47, stepharo <stepharo(a)free.fr> wrote: >>> >>> Esteban >>> I was thinking about the following this night. >>> >>> While I understand that we want configuration only it will slow us down like hell. >>> >>> Example >>> with guille we wanted to fix a problem (I do not remember which one) >>> we need a change to be done in rubric so we will have to publish the change in rubric repo >>> - (find it and add it) so the rubric repo should be there before >>> - then one guy of rubric should have a look >>> - then merge >>> - then publish an issue with a configuration >>> - then only then we can work >>> => result why do we need sync for me and guille to continue to work??? >>> => what if Alain in on vacation? >>> we stop working? >>> => Remember: We did Pharo especially because people in squeak did not want that we change >>> packages. >>> >>> Alternate process >>> - we do a fix we publish it in Pharo and yes this touches Rubric and >>> - we integrate it in Pharo head >>> - then the guy from rubric merge in their trunk when they want. >>> it should be part of the their process to merge always with pharo trunk >>> - At that point they can report a problem >>> - then they produce at their speed a new configuration >>> - then we integrate when ready their change >>> >>> >>> Stef >>> >>> > >

April 22, 2015

Re: [Pharo-dev] Integration process in presence of "external" project

by stepharo

Ok perfect then I will not work on changes that touch other projects. I suggest also guille not to try and we should focus on something else than in the image. > I disagree with your proposal. > It will be a mess, nobody will merge (because there will be no point on doing it) and we will not move out from a monolithic system. > What I propose is not an invention, is how big projects workâ¦ what you have to take into account is that any project under the Pharo umbrella does not have an owner, but a maintainer. That means if Alan is on vacation or he does not has the time to do the new configuration, anyone can doit. > > Yes, it can look slow, but that is because you are too used to the old workflow, and because right now system is not modular. > The method I propose will enhance modularity (while the older will, at least, not help), which means with time, changes will be applied just in one module and not along the full system like now. Ok I will let you enhance the modularity because my time is more expensive. Then when pharo will be modular I will come back. > > Of course with proper tools this will be faster, but I very much prefer people telling me âI need thisâ (thatâs why I did the integrator app, and modified the monkey to take and validate configurations), and we do it, that we abandon our pursuit of modularity because is uncomfortable at the beginning. You mixed everything. Did I talk about abandon our pursuit of modularity. Now what you are suggesting is that a change that can take 10 min will take several days to be done. From my concentration and energy point of view I will not work under such conditions. May I ask you when is the last time you work on remodularizing Pharo? Because I can say that I got my share with Guille but if Pharo does not respect my time then no problem I will do something else. > > We can modify also monticello or versioner (better monticello because everything will be closer, but using versioner API) to do a âsave new versionâ which would be more or less the same as a slice, but for a configuration, and it will: > > - save the packages associated to the configuration > - create a new version > - save the new configuration And? I will have to - enter the repo of the external project - fight with a configuration of a project that I do not know, - no thanks - or all the external project should work for real with versioner. - But people will have to look anyway at my changes but in addition they will have a potentially incompatible version (that may be they cannot load in there image). > > this will not be to much work (I think I can have it in a couple of days), it will help the process (because eventually everything should be managed through configurations (or PPM configurations), and it will allow us to keep a process that is better and validated.. > > TL;DR: Better enhance the tools than drop the process. Which process? Right now what you are proposing is just slowly the remodularisation from my point of view. Because if we have to wait (and we already faced it) that a change goes in rubric and in the rubric configuration so that we can ***continue*** to work. Then we are dead. Because other projects not under our control depend on rubric and I will not fix any of them. I'm sorry I will not work on tools. So I will work on my home projects. Stef > > Esteban > >> On 22 Apr 2015, at 07:47, stepharo <stepharo(a)free.fr> wrote: >> >> Esteban >> I was thinking about the following this night. >> >> While I understand that we want configuration only it will slow us down like hell. >> >> Example >> with guille we wanted to fix a problem (I do not remember which one) >> we need a change to be done in rubric so we will have to publish the change in rubric repo >> - (find it and add it) so the rubric repo should be there before >> - then one guy of rubric should have a look >> - then merge >> - then publish an issue with a configuration >> - then only then we can work >> => result why do we need sync for me and guille to continue to work??? >> => what if Alain in on vacation? >> we stop working? >> => Remember: We did Pharo especially because people in squeak did not want that we change >> packages. >> >> Alternate process >> - we do a fix we publish it in Pharo and yes this touches Rubric and >> - we integrate it in Pharo head >> - then the guy from rubric merge in their trunk when they want. >> it should be part of the their process to merge always with pharo trunk >> - At that point they can report a problem >> - then they produce at their speed a new configuration >> - then we integrate when ready their change >> >> >> Stef >> >> > >

April 22, 2015

Re: [Pharo-dev] [Moose-dev] QualityAssistant v0.4

by stepharo

Yuriy this is excellent because it will force us to have - better rules - rules with as many as automatic transformations as possible :) Excellent job. Stef

April 22, 2015

[pharo-project/pharo-core] bd8aef: 50004

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: bd8aef00a052613d0e0d41065e9d85ee42cf05c8 https://github.com/pharo-project/pharo-core/commit/bd8aef00a052613d0e0d4106… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-04-22 (Wed, 22 Apr 2015) Changed paths: M MonticelloGUI.package/MCConfigurationBrowser.class/class/opening/open.st M MonticelloGUI.package/MCWorkingCopyBrowser.class/class/instance creation/open.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script612.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script613.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50003.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50004.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M StartupPreferences.package/StartupPreferencesLoader.class/class/example/example.st M StartupPreferences.package/StartupPreferencesLoader.class/instance/private/buildStreamFor_.st M Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/defaults/defaultAvailableRepositories.st M Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/example/example.st A Tool-ConfigurationBrowser.package/MetacelloConfigurationBrowserPane.class/class/initialization/reset.st Log Message: ----------- 50004 15377 StartupLoader leftovers in StartupPreferencesLoader https://pharo.fogbugz.com/f/cases/15377 15354 Add <script> to #open in Monticello tools https://pharo.fogbugz.com/f/cases/15354 15355 Add MetaRepo for Pharo 40 in 5.0 config browser, also fix example method https://pharo.fogbugz.com/f/cases/15355 http://files.pharo.org/image/50/50004.zip

April 22, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50004 Home: https://github.com/pharo-project/pharo-core

April 22, 2015

Re: [Pharo-dev] [Pharo-users] QualityAssistant v0.4

by Cyril Ferlicot

Hi ! Your quality assistant say to me "repeated method in the superclass" (If a class is overriding a method, it should use a different code. Is meaningless to have a method in a class and in its superclass) but i've 3 methods into my class and all overrides a method with "^ shouldBeImplemented" in the superclass. I think something is wrong with this warning :) On 22 April 2015 at 16:45, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Good point, this brings up two problems. > > 1) The rule can improve detection by checking the type is the message is > sent to self > 2) Automatic fixing should display the changes and letting you decide > whether you want to apply them. > > 1st will take some time. 2nd will be soon in QA :) > > Uko > > > On 22 Apr 2015, at 16:33, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > Some weird behavior in quality assistant. Have a look at this method: > > duplicateVar: aVarName > > self show: 'Var: ', aVarName, ' redefinition ignored'. > > This raises the issue: âUse cascaded nextPutAll:âs instead of #, in > nextPutAll:â It also pops up the automatic rewrite icon, so I clicked on it > to see how it would transform the code. Result: > > duplicateVar: aVarName > self > show: 'Var: ' , aVarName; > show: ' redefinition ignored' > > Needless to say, thatâs not a behavior preserving transformation. > > > On Apr 22, 2015, at 03:58, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Please give me a feedback about your experience, as I want to make it even > more useful. Either write me an email, or open an entry at: > https://github.com/Uko/QualityAssistant/issues > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > -- Cheers Cyril Ferlicot

April 22, 2015

Re: [Pharo-dev] [Zinc, ZnPercentEncoder] problem encoding accents

by Sven Van Caekenberghe

Leo, I am sorry but you will have to be more specific and concrete. You are mixing lots of different things (encoding/decoding, form submit, JS - and there are details missing) - there are many places where you could have done something wrong. Please try to isolate your problem with a concrete short piece of code that I can run. Something along the lines of ZnDefaultServerDelegate>>formTest[1|2|3]: maybe. Sven > On 22 Apr 2015, at 15:46, Leo <lpaniceres(a)gmail.com> wrote: > > Sven > I saw the tests and they works fine. > The problem is on the field. > I have a form with javascript that gets addresses from Google Maps, then the form is submitted to my Pharo-Zinc-App. > When the form is submitted by Safari(OS X), Smalltalks receives the character with accent without encoding (no %). > Continuing with the Neuquen example, the 'accented eâ that should be %C3%A9 is received as the raw character. > With Firefox all works fine, the character is received with the correct encoding. > > So the problem is related to âdecode:â > In the research I also saw that some accented characters could be received as one character encoded, for example the 'accented eâ could be also %E9. > > thanks > Leo > > > > > >> El 21/4/2015, a las 18:26, pharo-dev-request(a)lists.pharo.org escribiÃ³: >> >> Date: Tue, 21 Apr 2015 22:59:52 +0200 >> From: Sven Van Caekenberghe <sven(a)stfx.eu> >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] [Zinc, ZnPercentEncoder] problem encoding >> accents >> Message-ID: <D819757B-96B3-4067-AC1F-9A8AD332456E(a)stfx.eu> >> Content-Type: text/plain; charset=utf-8 >> >> Leo, >> >> Are you sure you understand what percent encoding is ? >> >> Check the class comment of ZnPercentEncoding, it has links to a Wikipedia article. >> >> Did you see ZnPercentEncoderTests ? >> >> Anyway, I would think this is what you want to do: >> >> ZnPercentEncoder new encode: 'Neuqu?n, Neuqu?n Province, Argentina'. >> >> => 'Neuqu%C3%A9n%2C%20Neuqu%C3%A9n%20Province%2C%20Argentina' >> >> ZnPercentEncoder new decode: 'Neuqu%C3%A9n%2C%20Neuqu%C3%A9n%20Province%2C%20Argentina'. >> >> => 'Neuqu?n, Neuqu?n Province, Argentina' >> >> Seems to work fine, no ? >> >> What problem do you have with ZnUrl ? >> >> Sven >

April 22, 2015