- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 4f381f: 30621

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 4f381f0027728a768390f2f648edbdb1ac123088 https://github.com/pharo-project/pharo-core/commit/4f381f0027728a768390f2f6… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-04 (Wed, 04 Dec 2013) Changed paths: A CodeImport.package/MethodDeclaration.class/instance/importing/handleMissingBehavior.st M CodeImport.package/MethodDeclaration.class/instance/importing/importFor_.st A CodeImport.package/MissingClassError.class/README.md A CodeImport.package/MissingClassError.class/class/instance creation/className_.st A CodeImport.package/MissingClassError.class/definition.st A CodeImport.package/MissingClassError.class/instance/accessing/className_.st A CodeImport.package/MissingClassError.class/instance/accessing/superclassName.st A CodeImport.package/MissingClassError.class/instance/accessing/superclassName_.st A CodeImport.package/MissingClassError.class/instance/actions/asResumable.st A CodeImport.package/MissingClassError.class/instance/actions/defineClass.st A CodeImport.package/MissingClassError.class/instance/testing/isResumable.st M Komitter.package/Komitter.class/instance/accessing/stagingArea.st R Komitter.package/Komitter.class/instance/opening/open.st M Komitter.package/Komitter.class/instance/opening/openAndCommitToMonticello.st A Komitter.package/Komitter.class/instance/opening/openAndDo_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script276.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30621.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/DialogWindowModel.class/instance/initialize/initialize.st M Spec-Core.package/SpecDialogWindow.class/instance/accessing/toolbar_.st M Spec-Core.package/SpecDialogWindow.class/instance/protocol/setToolbarFrom_.st M Spec-Core.package/TextInputFieldModel.class/instance/initialization/initialize.st A Spec-MorphicAdapters.package/MorphicDialogWindowAdapter.class/instance/spec protocol/toolbar_.st A Spec-MorphicAdapters.package/MorphicTextInputFieldAdapter.class/instance/spec protocol/encrypted_.st M Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/protocol/lastClicked_.st Log Message: ----------- 30621 - issue 12317: Better way to let the user handle missing class when loading code https://pharo.fogbugz.com/f/cases/12317/Better-way-to-let-the-user-handle-m… - issue 12335: Some fixes https://pharo.fogbugz.com/f/cases/12335/Some-fixes - issue 12336: Do not open Komitter modal https://pharo.fogbugz.com/f/cases/12336/Do-not-open-Komitter-modal http://files.pharo.org/image/30/30621.zip

Dec. 4, 2013

Re: [Pharo-dev] Opal hook?

by StÃ©phane Ducasse

>> Ok I will check something on UndefinedObject to start with. >> Then it would be fun to prototype a kind of strategy hiearchy on the side (extracted from also) behavior of OCSemanticsError >> It was nice to see it and since now I'm ok to have a look at the compiler code it was interesting. >> > > The current design is motivated mostly by backward compatibility, not anything else. I see :) I would really to see an headless, interactive and scriptable scenarios to be exercised. So this is good it will get better :) Stef

Dec. 4, 2013

Re: [Pharo-dev] Opal hook?

by Marcus Denker

On 04 Dec 2013, at 20:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> As a clear example, this is just bad that each time we want to change the UI message we have to change the compiler exception. >>> ugly at wish. >>> >>> I have no cycle to fix that now. I will check if I can get something in UndefinedObject so that I can continue to work on my task. >>> >> >> The whole exception / error handling of the compiler needs to be deeply rethought. >> Sadly I have no cycles free in my brain to even start to think about it, and, even more important, we should wait until the old >> Compiler is removedâ¦ > > Ok I will check something on UndefinedObject to start with. > Then it would be fun to prototype a kind of strategy hiearchy on the side (extracted from also) behavior of OCSemanticsError > It was nice to see it and since now I'm ok to have a look at the compiler code it was interesting. > The current design is motivated mostly by backward compatibility, not anything else. Marcus

Dec. 4, 2013

Re: [Pharo-dev] Opal hook?

by StÃ©phane Ducasse

>> As a clear example, this is just bad that each time we want to change the UI message we have to change the compiler exception. >> ugly at wish. >> >> I have no cycle to fix that now. I will check if I can get something in UndefinedObject so that I can continue to work on my task. >> > > The whole exception / error handling of the compiler needs to be deeply rethought. > Sadly I have no cycles free in my brain to even start to think about it, and, even more important, we should wait until the old > Compiler is removedâ¦ Ok I will check something on UndefinedObject to start with. Then it would be fun to prototype a kind of strategy hiearchy on the side (extracted from also) behavior of OCSemanticsError It was nice to see it and since now I'm ok to have a look at the compiler code it was interesting. Stef > > Marcus >

Dec. 4, 2013

Re: [Pharo-dev] [ANN] Roassal 3d

by Marcus Denker

On 04 Dec 2013, at 20:30, milton mamani <akevalion(a)gmail.com> wrote: > > 3. Providing a script is so "old style" and hard to remember - why not define a #stable > and put your config into MetaRepoForPharo30 > So others can easily load it via ConfigurationBrowser with a few clicks in a fresh image. even better: have a jerkins build where people can download an imageâ¦ Marcus

Dec. 4, 2013

Re: [Pharo-dev] [ANN] Roassal 3d

by milton mamani

Hi Alexandre, Ronie, Milton, first: this is a cool project! Then a few comments: 1. When using the script in a fresh Pharo3.0 Latest update: #30620 it complains: This package depends on the following classes: ROAthensMorph You must resolve these dependencies before you will be able to load these definitions: R3MorphOverlay clear Nonetheless one can proceed and it loads This is a bug, we are working to fix it. 2. If I use the samples from the tutorial PDF and copy them into a Pharo workspace they are not accepted by Pharo - looks like an encoding issue in the PDF (when copying from Adobe PDF viewer on Windows into Pharo) When I type the samples manually they work There is an issue with dropbox and PDF. You can download the file and open it, that should work. 3. Providing a script is so "old style" and hard to remember - why not define a #stable and put your config into MetaRepoForPharo30 So others can easily load it via ConfigurationBrowser with a few clicks in a fresh image. We are going to review|work on that 4. Did I already told you that this is a cool project? 5. See 4. Thank you Bye 2013/12/4 Torsten Bergmann <astares(a)gmx.de> > Hi Alexandre, Ronie, Milton, > > first: this is a cool project! > > Then a few comments: > > 1. When using the script in a fresh Pharo3.0 Latest update: #30620 it > complains: > > This package depends on the following classes: > ROAthensMorph > You must resolve these dependencies before you will be able to load > these definitions: > R3MorphOverlay > clear > > Nonetheless one can proceed and it loads > > 2. If I use the samples from the tutorial PDF and copy them into a Pharo > workspace they are not accepted by Pharo - looks like an encoding > issue in the PDF > (when copying from Adobe PDF viewer on Windows into Pharo) > > When I type the samples manually they work > > 3. Providing a script is so "old style" and hard to remember - why not > define a #stable > and put your config into MetaRepoForPharo30 > So others can easily load it via ConfigurationBrowser with a few > clicks in a fresh image. > > 4. Did I already told you that this is a cool project? > > 5. See 4. > > Bye > T. > >

Dec. 4, 2013

Re: [Pharo-dev] Opal hook?

by Marcus Denker

On 04 Dec 2013, at 20:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> AnUnknownClass subclass: #Adaptor1Example >> instanceVariableNames: 'customers accountID address name phoneNumber' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Examples-Cookbook' >> >> executes the default action for OCUndeclaredVariableWarning, which is opening a pop-up titled: "Unknown variable ...". Here the error is raised at compilation time, therefore it would have no effect to wrap this with a #on:do: > > I > to me CompilerException should have nothing to do with UI and popup. Then we should be able to pass objects that knows how to handle > the errors in interactive way or not. > > As a clear example, this is just bad that each time we want to change the UI message we have to change the compiler exception. > ugly at wish. > > I have no cycle to fix that now. I will check if I can get something in UndefinedObject so that I can continue to work on my task. > The whole exception / error handling of the compiler needs to be deeply rethought. Sadly I have no cycles free in my brain to even start to think about it, and, even more important, we should wait until the old Compiler is removedâ¦ Marcus

Dec. 4, 2013

Re: [Pharo-dev] Komitter

by StÃ©phane Ducasse

Nicolas >From what I understand Kommitter just filters the entities that will be passed as modified and as such does not change the ancestry of a package. Stef On Dec 4, 2013, at 8:12 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Does Kommitter enables partial commits (cherry picking) for a package? > If so, my question is how does it deal with MC ancestry? > > Imagine I have a package- A.247 from my-trunk. > I merge some A.312 from my-work repository with work in progress. > Now I want to cherry pick the changes which are OK, and publish only those to my-trunk. > I do so in my-trunk/A.313. > Will A.312 be in the ancestry of A.313? > Logically as MC is working, yes, because it is in the ancestry of in-image working copy. > > What if I later download A.313 from my-trunk in a fresh image and try to merge A.312 to finish the work in progress? > IMO, this is not possible, A312 being an ancestor, no change will happen. > > So, it sounds like when I committed my-trunk/A.313 with partial changes, I should have commited my-work/A.314 immediately after with the rest of pending changes... > If I forgot to do so and threw my image away, from a fresh image, it is still possible to load A.312, merge A.313, and publish A.314 in my-work repo. > > But then it rather complicates the flow... If we commit/merge carelessly, we might throw away some valuable work in progress. > The fear of such scenario prevented us to integrate a change from Bert in Squeak/trunk enabling such partial commits (directly from MC UI in Squeak case). > > > 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > +1 > > > Thanks once more for your effort. This is a really important tool for me. > > > > Uko > > > > >

Dec. 4, 2013

Re: [Pharo-dev] Komitter

by Nicolas Cellier

Err, from a fresh image, we should not merge A.313 but adopt it in our ancestry, else merging will remove all the pending changes... 2013/12/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Does Kommitter enables partial commits (cherry picking) for a package? > If so, my question is how does it deal with MC ancestry? > > Imagine I have a package- A.247 from my-trunk. > I merge some A.312 from my-work repository with work in progress. > Now I want to cherry pick the changes which are OK, and publish only those > to my-trunk. > I do so in my-trunk/A.313. > Will A.312 be in the ancestry of A.313? > Logically as MC is working, yes, because it is in the ancestry of in-image > working copy. > > What if I later download A.313 from my-trunk in a fresh image and try to > merge A.312 to finish the work in progress? > IMO, this is not possible, A312 being an ancestor, no change will happen. > > So, it sounds like when I committed my-trunk/A.313 with partial changes, I > should have commited my-work/A.314 immediately after with the rest of > pending changes... > If I forgot to do so and threw my image away, from a fresh image, it is > still possible to load A.312, merge A.313, and publish A.314 in my-work > repo. > > But then it rather complicates the flow... If we commit/merge carelessly, > we might throw away some valuable work in progress. > The fear of such scenario prevented us to integrate a change from Bert in > Squeak/trunk enabling such partial commits (directly from MC UI in Squeak > case). > > > 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> +1 >> >> > Thanks once more for your effort. This is a really important tool for >> me. >> > >> > Uko >> > >> >> >> >

Dec. 4, 2013

Re: [Pharo-dev] Komitter

by Nicolas Cellier

Does Kommitter enables partial commits (cherry picking) for a package? If so, my question is how does it deal with MC ancestry? Imagine I have a package- A.247 from my-trunk. I merge some A.312 from my-work repository with work in progress. Now I want to cherry pick the changes which are OK, and publish only those to my-trunk. I do so in my-trunk/A.313. Will A.312 be in the ancestry of A.313? Logically as MC is working, yes, because it is in the ancestry of in-image working copy. What if I later download A.313 from my-trunk in a fresh image and try to merge A.312 to finish the work in progress? IMO, this is not possible, A312 being an ancestor, no change will happen. So, it sounds like when I committed my-trunk/A.313 with partial changes, I should have commited my-work/A.314 immediately after with the rest of pending changes... If I forgot to do so and threw my image away, from a fresh image, it is still possible to load A.312, merge A.313, and publish A.314 in my-work repo. But then it rather complicates the flow... If we commit/merge carelessly, we might throw away some valuable work in progress. The fear of such scenario prevented us to integrate a change from Bert in Squeak/trunk enabling such partial commits (directly from MC UI in Squeak case). 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > +1 > > > Thanks once more for your effort. This is a really important tool for me. > > > > Uko > > > > >

Dec. 4, 2013