August 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 812bc6: 50254

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 812bc6f3f68a89457b21b07a8e5236e0c6d5bb1b https://github.com/pharo-project/pharo-core/commit/812bc6f3f68a89457b21b07a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-20 (Thu, 20 Aug 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version1182_.st M OpalCompiler-Tests.package/OCBytecodeGeneratorTest.class/instance/helper/newBytecodeGen.st M Rubric.package/RubAbstractSmalltalkMode.class/definition.st M Rubric.package/RubPluggableTextMorphExample.class/instance/menu/codePaneMenu_shifted_.st M Rubric.package/RubPluggableTextMorphExample.class/instance/view creation/newScrolledTextMorph.st M Rubric.package/RubSHTextStylerST80.class/definition.st A Rubric.package/RubScrolledTextMorph.class/instance/accessing/editingModeClass.st M Rubric.package/RubShoutStylerDecorator.class/definition.st M Rubric.package/RubSmalltalkCodeMode.class/definition.st M Rubric.package/RubSmalltalkCommentMode.class/definition.st M Rubric.package/RubSmalltalkEditor.class/class/keymapping/buildShortcutsOn_.st M Rubric.package/RubSmalltalkEditor.class/definition.st M Rubric.package/RubSmalltalkScriptingMode.class/definition.st M Rubric.package/RubTextClassLink.class/definition.st M Rubric.package/RubTextMethodLink.class/definition.st M Rubric.package/RubTextVariableLink.class/definition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50253.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50254.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50253.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50254.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-FileList.package/FileList.class/class/initialization/initialize.st Log Message: ----------- 50254 16320 Update configuration of Rubric https://pharo.fogbugz.com/f/cases/16320 16313 fix tests failing when unloading old compiler https://pharo.fogbugz.com/f/cases/16313 16315 SimpleServerEntry should use a pragma and use them to declare them https://pharo.fogbugz.com/f/cases/16315 http://files.pharo.org/image/50/50254.zip

Aug. 20, 2015

Re: [Pharo-dev] Komiiter is a piece of crap

by Martin Dias

:-) About the selection issue, it was reported by Camillo last year: 12977. I just resolved it as duplicate. BTW, I reported a defect in case 16203 (Wrong diff when changing the package of an extension method), and it would be great if somebody can check if it's reproducible. MartÃn El jue., 20 ago. 2015 a las 12:39, Thomas Heniart (<heniart.thomas(a)gmail.com>) escribiÃ³: > Hi, > > I made some changes on the Komitter, there is no more fork, scary wheel > and last thing > is when you select a node state of checkbox doesn't change. > All these changes are in version 50251 :) > > Cheers, > Thomas > > 2015-08-16 23:06 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi guys, >> >> We should really seriously revisit Komitter (logic). This is **several** >> times that >> saving with it freezes my image and I cannot get it back. I'm forced to >> kill it from the OS part. >> This is not acceptable. >> I prefer no tool that a tool that forces me to recover my work by hand or >> lose it. >> I'm sorry but I think that it was developed too fast and we should also >> remove all the forks and other bad smells from it. >> Frankly I would remove it from Pharo50 or fix it. >> >> Stef >> >> >> >

Aug. 20, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 20, 2015

[pharo-project/pharo-core] 45008d: 50253

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 45008d9aadb7a1b2308aef09388c865088aa104d https://github.com/pharo-project/pharo-core/commit/45008d9aadb7a1b2308aef09… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-20 (Thu, 20 Aug 2015) Changed paths: M CodeImport.package/EvaluateCommandLineHandler.class/instance/commands/evaluate_.st R Graphics-Display Objects.package/Form.class/class/initialization/unload.st R Graphics-Display Objects.package/Form.class/class/initialize-release/initialize.st A Graphics-Files.package/extension/Form/class/initialize.st A Graphics-Files.package/extension/Form/class/unload.st R Nautilus.package/AbstractNautilusUI.class/instance/class comment pane/acceptSourceCodeFromView.st A Nautilus.package/AbstractNautilusUI.class/instance/source code area/acceptSourceCodeFromView.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/showScriptCode_.st M Nautilus.package/AbstractNautilusUI.class/instance/source code area/showSourceCode_.st M Refactoring-Critics.package/RBImplementedNotSentRule.class/instance/cache/literals.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50252.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50253.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50252.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50253.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-ExternalBrowser.package/RingChunkImporter.class/instance/private/scannedSource_.st Log Message: ----------- 50253 16316 Form should not rgisterFileReader inside the Graphics package https://pharo.fogbugz.com/f/cases/16316 16312 Fix some references to the old compiler https://pharo.fogbugz.com/f/cases/16312 16080 RBImplementedButNotSent always true https://pharo.fogbugz.com/f/cases/16080 16306 Clear undo cache in Nautilus when changing source code https://pharo.fogbugz.com/f/cases/16306 http://files.pharo.org/image/50/50253.zip

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by Thierry Goubier

2015-08-20 11:53 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > my âproposalâ is just a fast sketch made to illustrate how I would like > to show certain functionality, it does not take into account any other > functionalityâ¦ If I finish my browser proposal ever, it will have a lot > more buttons in the toolbar :) > about hierarchy I think it should spawn a new browser, as beforeâ¦ but it > is still something we need to play with it. > > > > NOoooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > The same way we use all the time variables. > > > *we* use them all the time, but most people does not use them never :) > anyway: an option in a tab is one click, same as with a button: not hardâ¦ > and we can play with the information we show in auxiliary panels better :) > > > We could have a set up for normal dev and one for indiana jones. > I'll put you in the Indiana Jones category :) Whip-enabled system browser! Thierry > > > > > Esteban > > > Stef > > Le 19/8/15 11:50, Esteban Lorenzano a Ã©crit : > > > On 19 Aug 2015, at 11:44, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > <Screen Shot 2015-08-19 at 11.10.41.png> >> >> â¦ but arriving to it is not so easy. >> >> In conclusion: We are doing some right steps. It is not finished, but we >> are not going to go back to older way :) >> > > Hi Esteban, > > My opinion is that you're still tied a lot to the Smalltalk 80's way... > Which is good: someone coming from 1980 would be able to use Nautilus ;) > > My critics on that design: the tabs are nice and certainly help see that a > class has a class side. Overall look is more up to date. Tabs headers, > scroll bars, etc... take far too much space: work area (the code area) is > 39% of overall window size, and 68% counting in the context (package, > class, protocol and method) (Numbers are worse on a small window, of > course, but I guess some do work on small screens). > > It will be nice to see simpler / cleaner Nautilus code coming along :) > > > yes, of course you are right :) > the GTools guys are working in a complete replacement, and Iâm sure it > will be a lot betterâ¦ but we will always need a backdoorâ¦ and I would like > to have a good browser even as a backdoor. > (also, our philosophy is incremental: we improve what we have while we > wait for the break-thru improvements) > > Esteban > > ps: for me the âcode areaâ is not equivalent to the âwork areaâ: I spend > much more time understanding a problem than coding it, and for that a view > of the method *in the context* is better) > > > Thierry > > > > > >

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by Thierry Goubier

2015-08-20 11:51 GMT+02:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > I took a look at the class you recommended and now I see what you mean.I > am glad this is not deeply tied to the system browser and is something > other tools can use as well with ease. Very flexible too. Looks like the > tools only expose a fraction of the power of the environment . > Well, behind all things RB (the Refactoring Browser[1]) you have a complete model of Smalltalk code. It allows refactoring tools to work on live code but also on non-live code. For example, in SmaCC, which is implemented by the same guys, the code for a parser is generated entirely as refactorings (i.e. non-live code), then refactored for optimisations for both code performance and to minimize the number of refactorings (but still non-live), then split to fit the Cog Jit limits (my work!), and then compiled to the live system in one (large) step. But why am I saying that? To show that those environments are very flexible (and the tools around as well), that they may work on non-live code (for example, a non-loaded package) and that most of the IDE needed functions in practice apply on a model linked to the live code, including when using them through Nautilus. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.9246&rep=rep1&t… > Makes me wonder whether environment would be a good idea to be used as > some sort of namespaces. > The difference between an environment and a namespace is at the compiler level: can you make the compiler use an environment when compiling a method? I think that Marcus has done things in that direction recently (such as allowing you to add "virtual" instance variables before compiling a method). Also an environment never "renames" stuff, it only "restricts" what is visible. At the programmer level, a Namespace is the ability to have two pieces of code where the class named Morph is an entirely different class, and that you can't understand the code anymore because you're never sure of what a global refers to (since it may be renamed via an import statement)... Some will say it's a feature ;) Thierry > > On Thu, Aug 20, 2015 at 9:08 AM Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >> Le 19/08/2015 20:26, Dimitris Chloupis a Ã©crit : >> > >> > >> > On Wed, Aug 19, 2015 at 5:51 PM Sean P. DeNigris <sean(a)clipperadams.com >> > <mailto:sean@clipperadams.com>> wrote: >> > >> > kilon.alios wrote >> > >> > >> > For example, let's say your project has a class that implements a >> > generically-named method, like #asMorph. If you try to rename that >> > method >> > via Refactoring, Pharo will try to rename all #asMorph methods, and >> > update >> > all senders, in the entire system, not just yours. But if you scope >> the >> > browser first to your package or class, you can restrict the >> > environment to >> > which the refactoring is applied >> > >> > >> > This sounds useful indeed. Is just the browser aware of the scope or is >> > also the pharo environment aware of the scope too ? It would be nice if >> > the scope could expand to include multiple packages , or is this >> > something left to groups ? >> >> What is happening is that many commands linked to the IDE (refactorings, >> searches) have an environment entity. By default, this environment is >> Smalltalk, but it can be a subset of it, and any subset of it. >> >> Have a look into the RBBrowserEnvironment class and subclasses and you >> will see all the variants. For example, a RBPackageEnvironment will >> scope to one or multiple packages. >> >> Thierry >> >> >> >>

Aug. 20, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 20, 2015

[pharo-project/pharo-core] 130297: 50252

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 130297f52e1da90977b87efb64c280551794b80d https://github.com/pharo-project/pharo-core/commit/130297f52e1da90977b87efb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-20 (Thu, 20 Aug 2015) Changed paths: M AST-Core.package/RBParser.class/instance/accessing/initializeParserWith_.st A CodeExport.package/extension/WriteStream/instance/nextChunkPut_.st A CodeExport.package/extension/WriteStream/instance/timeStamp.st M Collections-Streams.package/ManifestCollectionsStreams.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R Collections-Streams.package/WriteStream.class/instance/filein%2Fout/nextChunkPutWithStyle_.st R Collections-Streams.package/WriteStream.class/instance/filein%2Fout/nextChunkPut_.st R Collections-Streams.package/WriteStream.class/instance/filein%2Fout/timeStamp.st M Collections-Strings.package/ManifestCollectionsStrings.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R Collections-Strings.package/WideString.class/instance/testing/includesUnifiedCharacter.st R Collections-Strings.package/WideString.class/instance/testing/isUnicodeStringWithCJK.st R Compression.package/extension/Bitmap/instance/compressGZip.st A Multilingual-OtherLanguages.package/extension/WideString/instance/includesUnifiedCharacter.st A Multilingual-OtherLanguages.package/extension/WideString/instance/isUnicodeStringWithCJK.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50251.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50252.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50251.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50252.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Transcript.package/ThreadSafeTranscript.class/instance/accessing/black.st R Transcript.package/ThreadSafeTranscript.class/instance/accessing/white.st Log Message: ----------- 50252 16268 SyntaxErrorNotification from styler for single double quotes https://pharo.fogbugz.com/f/cases/16268 16284 Compression should not depend on Graphics-Primtives https://pharo.fogbugz.com/f/cases/16284 16281 Collections should not depend on Multilingual-OtherLanguages https://pharo.fogbugz.com/f/cases/16281 16287 Transcript should not depend on Graphics-Primitives https://pharo.fogbugz.com/f/cases/16287 http://files.pharo.org/image/50/50252.zip

Aug. 20, 2015

Re: [Pharo-dev] Komiiter is a piece of crap

by Thomas Heniart

Hi, I made some changes on the Komitter, there is no more fork, scary wheel and last thing is when you select a node state of checkbox doesn't change. All these changes are in version 50251 :) Cheers, Thomas 2015-08-16 23:06 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi guys, > > We should really seriously revisit Komitter (logic). This is **several** > times that > saving with it freezes my image and I cannot get it back. I'm forced to > kill it from the OS part. > This is not acceptable. > I prefer no tool that a tool that forces me to recover my work by hand or > lose it. > I'm sorry but I think that it was developed too fast and we should also > remove all the forks and other bad smells from it. > Frankly I would remove it from Pharo50 or fix it. > > Stef > > >

Aug. 20, 2015

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Dimitris Chloupis

Tudor this great news, I was not aware you guys were moving to a similar direction because of that class comment. Where I can follow your progress , is it added directly to Moose or is there a special repo for these enhancements ? I would hate to waste time coding something you will be coding too. Its not as if I am going to implement these features any time soon anyway. On Thu, Aug 20, 2015 at 1:05 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > I was thinking something similar. Its not a crazy idea at all. Auto > completion already has a detailed view for class comments if its enabled in > settings. However a more minimal gui will be needed not to make the life of > the user difficult . > > On Thu, Aug 20, 2015 at 12:36 PM Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi >> >> 2015-08-20 6:54 GMT+03:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> >>>> Auto-completion in Pharo is really bad. It would be fantastic to >>>> improve it. >>>> >>>> >>> Yes indeed, my effort for now is focused in documenting it. I cannot >>> improve what I dont understand. Then will see if I can improve it, by >>> making it more customizable or making it a bit smarter. >>> >> >> I have crazy idea to integrate GTSpotter to autocompletion pane to allow >> immediate search on existed texts. What you think about this? >> >

Aug. 20, 2015