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

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Yuriy Tymchuk

Ok, so here it goes. There was a main method: #package:class:category:method: (https://github.com/pharo-project/pharo-core/blob/8a1f79b44b14f8eafaf6d91a8b… <https://github.com/pharo-project/pharo-core/blob/8a1f79b44b14f8eafaf6d91a8b…>). This method was setting a state of the model by sending #selectedPackage:, #selectedClass:, â¦â¦â¦ to self. Each of this 4 methods were announcing if the parameter was not nil. As you may guess #package:class:category:method: was used through the whole system with occasional nil params. I hate working with nils. So what I did was to break the method into 4: #package: #package:class: #package:class:protocol: #package:class:protocol:method: So now there is no nil passing anymore. E.g. if you select only a class, you send #package:class:. Then Iâve moved announcements from #selectedPackage:, #selectedClass:, â¦â¦â¦ to the newly created 4 methods. Also now announcements know the parent scope i.e. NautilusProtocolSelected besides protocol knows also about the class and package that played a role on the selection. This are essentially all the changes. The issue that occurred later (when selecting a package class was not deselected) is because #selectedClass: was doing `self selectedProtocol: nil`, same with protocol. But #selectedPackage: was not âdeselectingâ a class, probably because it was handled by calling `model package: SomePackage class: nil category: nil method: nil` in a first place. > On 05 Sep 2015, at 21:39, stepharo <stepharo(a)free.fr> wrote: > > > > Le 5/9/15 16:49, Yuriy Tymchuk a Ã©crit : >> I can give you a short explanation for the sake of more people knowing how Nautilus works. > Yes please if you have some time. > What I do not like is that we pass nil to indicate that there is no selection. I was thinking that an hierarchy of null objects could help but this is difficult to > foresee if it will make sense. > I also that all the logic update without reselecting is complex. > I started to read the code and also move some condition about the model to the model class :). > I would like to do just a simple pass reading all the code and not changing much to get now yet another better feel of nautilus. > I will also remove the Nautilus help. > I would like to rename the NautilusRefactoring because it is not about nautilus but about RB. > >> >> Regarding diffs and knowledge sharing, we should have a normal code review support with something like gerrit. > > thomas was working on a code review tool and skip is taking over so I hope that we will have it. >> >> Uko >> >>> On 05 Sep 2015, at 15:46, stepharo <stepharo(a)free.fr> wrote: >>> >>> As you wish. Thanks for your time. >>> >>> Now I will get really frustrated because I will not know simply what you did and I will have missed a good occasion >>> to learn something. This is what sending the diff in text simply give us. >>> >>> Stef >>> >>> >>> Le 5/9/15 14:09, Yuriy Tymchuk a Ã©crit : >>>> I found the issue. Fix almost ready. Should I reopen the case, or create a new one? >>>> >>>> Uko >>>> >>>> >>>> >>>>> On 05 Sep 2015, at 13:59, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>>> >>>>> On 05-09-15 08:51, stepharo wrote: >>>>>> Hi >>>>>> >>>>>> I do not know if this is linked to recent changes but we cannot remove >>>>>> classes or move them to another package >>>>> I can move them to another package using drag-and-drop (issue 16488) >>>>> in 50305 >>>>> >>>>> >>>>> Stephan >>>>> >>>>> >>>> >>> >> >> > >

Sept. 7, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by Yuriy Tymchuk

Yes, I know, but Stef was referring to deleting a method. Also I donât really know how I can fix the stuff with instance variable. I need to have a separate process in order not to slow down the browsing in Nautilus. Uko > On 07 Sep 2015, at 12:01, Nicolai Hess <nicolaihess(a)web.de> wrote: > > "and add an instance *variable*" :) > > 2015-09-07 12:01 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: > > Just open Nautilus on class "Model" and add an instance. > > > > 2015-09-07 0:56 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: > Also, when if this kind of error happens again, can you please fuel it out and sent it to me? Having a stack can be helpful in understanding. > > Uko > > > On 06 Sep 2015, at 22:17, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > > > I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method > > but I failed. > > I got again this bug. > > What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. > > But I cannot reproduce it. > > > > Stef > > > > > >

Sept. 7, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by Nicolai Hess

"and add an instance *variable*" :) 2015-09-07 12:01 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > Just open Nautilus on class "Model" and add an instance. > > > > 2015-09-07 0:56 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Also, when if this kind of error happens again, can you please fuel it >> out and sent it to me? Having a stack can be helpful in understanding. >> >> Uko >> >> > On 06 Sep 2015, at 22:17, stepharo <stepharo(a)free.fr> wrote: >> > >> > I thought that I could reproduce the QA concurrent access raising a DNU >> when we remove a method >> > but I failed. >> > I got again this bug. >> > What I did was selecting a method in Nautilus and removing this method >> after an implementors and from the message list browser. >> > But I cannot reproduce it. >> > >> > Stef >> > >> >> >> >

Sept. 7, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by Nicolai Hess

Just open Nautilus on class "Model" and add an instance. 2015-09-07 0:56 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Also, when if this kind of error happens again, can you please fuel it out > and sent it to me? Having a stack can be helpful in understanding. > > Uko > > > On 06 Sep 2015, at 22:17, stepharo <stepharo(a)free.fr> wrote: > > > > I thought that I could reproduce the QA concurrent access raising a DNU > when we remove a method > > but I failed. > > I got again this bug. > > What I did was selecting a method in Nautilus and removing this method > after an implementors and from the message list browser. > > But I cannot reproduce it. > > > > Stef > > > > >

Sept. 7, 2015

Pillar 1.1.0 released

by Damien Cassou

Cyril Ferlicot and I have polished Pillar 1.0.0 a little. Here is 1.1.0 changelog: - add shebang to generated pillarPostExport.sh - improve pillarPostExport.sh messages a little - HTML exporter - output a <figure> if and only if the Pillar figure has both a caption and a label - LaTeX exporter - output a \begin{figure} if and only if the Pillar figure has both a caption and a label Cyril migrated the list of issues and feature requests from smalltalkhub.com to https://github.com/pillar-markup/pillar/issues Please report issues, describe feature requests and ask questions there. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 7, 2015

Re: [Pharo-dev] Mongo - find object by id

by Sabine Manaa

Hi Stephane, my changes have been integrated into the document by Johan and I checked as ok, so it is done. Regards Sabine 2015-08-18 12:49 GMT+02:00 Sabine Manaa <manaa.sabine(a)gmail.com>: > Hi Stephane, > > ok, I have put all my suggestions in a pull request. Please feel free to > change, delete .... it is only a suggestion. I am interested in feedback! > > Regards > Sabine > > 2015-08-17 14:53 GMT+02:00 Sabine Manaa <manaa.sabine(a)gmail.com>: > >> Hi Steph, >> >> thanks. I am editing my suggestions and tell you when finished. >> >> Regards >> Sabine >> >> 2015-08-16 19:29 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >>> >>> Hi Stephane, >>> >>> I have collected my points to add to the book. >>> >>> Can you give me an entry point how to do a pull request on the paper >>> please? >>> Pillar? Editor? Script? Sounds complicated for the first time. >>> >>> If you can use pillar this is better, else we will do a pass and convert >>> it to pillar >>> Since the chapter is for the book that should be out I'm not that >>> editing it directly is a good. >>> Now what we can do is to work on on a separate file that Johan or >>> Esteban can merge to the chapter once >>> it is finished. >>> >>> What I was thinking about is to have a series of extras section >>> with for example some of the problems and solutions you encountered. >>> >>> >>> How to handle loop within your domain? >>> >>> How to find an object by id? >>> >>> ... >>> >>> The original file is here: >>> >>> >>> https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Voya… >>> >>> >>> I created a VoyageAdditionalText.pier that you can edit. >>> >>> And this is easy >>> - you can go to the page >>> - fork the folder >>> - edit in the web the file and send a pull request. >>> >>> if this is not working, we will add you to the project and you can >>> directly edit this file. >>> >>> Regards >>> Sabine >>> >>> >>> >>> 2015-08-13 16:17 GMT+02:00 stepharo <stepharo(a)free.fr>: >>> >>>> >>>> Hi Stephane, >>>> >>>> sure, I am happy to give something back to the community. I dont have >>>> so much time because of my baby but I will try my best. >>>> >>>> Where shall I put it in? >>>> >>>> >>>> You can do pull requests in the paper. This way they will be close to >>>> the original version. >>>> >>>> >>>> Sabina >>>>> >>>>> you know what I would really love from you .... >>>>> this is that you reread the Voyage chapter and make a list of the >>>>> problems you faced and that are not described in the chapter. >>>>> You can write it in any bad ways and we can do a edit phase after, >>>>> >>>>> Why do I ask that? Because I'm stupid in Mongo and I would love to >>>>> have a good doc. >>>>> And only the people facing the problems can spot them nicely. >>>>> I often write doc on things that I do not know but this is not working >>>>> well because I'm slow in that case and .... I could be much better >>>>> doing something else where I'm good at. >>>>> >>>>> Stef >>>>> >>>>> Le 12/8/15 09:40, Sabine Manaa a Ã©crit : >>>>> >>>>>> Hi, >>>>>> >>>>>> on mongo console, this brings me a persons information from mongo db >>>>>> db.Persons.find({"_id" : ObjectId("75b900000000000000000000")}) >>>>>> >>>>>> I try to query the same person from pharo and I do not succeed. >>>>>> >>>>>> This makes my image hanging: >>>>>> RKAPerson selectMany: {('_id' -> (OID >>>>>> value:'75b900000000000000000000'))} >>>>>> >>>>>> also other variations e.g. >>>>>> RKAPerson selectMany: {('_id' -> ('75b900000000000000000000')). } >>>>>> asDictionary. >>>>>> >>>>>> do not work >>>>>> >>>>>> Other queries like >>>>>> RKAPerson selectMany:{('lastName' -> ('Maier')).} asDictionary. >>>>>> or >>>>>> RKAPerson selectMany:{('nextTripNumber' -> (57)).} asDictionary. >>>>>> >>>>>> work fine. >>>>>> >>>>>> How can I query for an object with the object id? >>>>>> >>>>>> Regards >>>>>> Sabine >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.world.st/Mongo-find-object-by-id-tp4842231.html >>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>>> Nabble.com. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >

Sept. 7, 2015

WhatsUp from: 2015-09-07 until: 2015-09-20

by seaside＠rmod.lille.inria.fr

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: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2015-09-20 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Sept. 7, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by Yuriy Tymchuk

Also, when if this kind of error happens again, can you please fuel it out and sent it to me? Having a stack can be helpful in understanding. Uko > On 06 Sep 2015, at 22:17, stepharo <stepharo(a)free.fr> wrote: > > I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method > but I failed. > I got again this bug. > What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. > But I cannot reproduce it. > > Stef >

Sept. 6, 2015

Re: [Pharo-dev] Did no find yet a way to reproduce QA concurrent access

by Yuriy Tymchuk

I think that it is related to how I was working with Nautilus announcements. Now as announcements are changed, I can improve that. Just give me a bit of time :) Uko > On 06 Sep 2015, at 22:17, stepharo <stepharo(a)free.fr> wrote: > > I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method > but I failed. > I got again this bug. > What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. > But I cannot reproduce it. > > Stef >

Sept. 6, 2015

Did no find yet a way to reproduce QA concurrent access

by stepharo

I thought that I could reproduce the QA concurrent access raising a DNU when we remove a method but I failed. I got again this bug. What I did was selecting a method in Nautilus and removing this method after an implementors and from the message list browser. But I cannot reproduce it. Stef

Sept. 6, 2015

Re: [Pharo-dev] chunk file format (unrecoverable changes)

by stepharo

Le 6/9/15 21:56, Nicolai Hess a Ã©crit : > Do we have a documentation about the format of > - class definitions > - methods > - class comments > for the changes file ? Not that I know besides the implementation. > > I am asking because some entries are using two separator > "! !" > and some only one > "!" > And we have a problem with the "Recover lost changes" browser > (https://pharo.fogbugz.com/f/cases/16498/unrecoverable-changes) I imagine that this is related also to the bugs you mentioned and I was fixing by improving the code importer. Is it that? Because the parser is brittle to my eyes because it is based on heuristics and I do not know if we cover all the case. > and I am not sure if this is a bug on the code importer > or if it is a bug on how we write changes to the changes file. May be opening a 40.changes with another editor ? > > > nicolai >

Sept. 6, 2015

Re: [Pharo-dev] remove MczInstaller?

by stepharo

Le 5/9/15 18:24, Marcus Denker a Ã©crit : >> On 05 Sep 2015, at 15:54, stepharo <stepharo(a)free.fr> wrote: >> >> Are you sure that it is not used when we drag an MCZ on the desktop? > No, at least I do not think so. > > itâs the installer that was added to Squeak before Monticello. The idea is that it can be used > to install .mzc files even when Monticello is not there. > > I was thinking of removing it in the past, but for a real modular system it might be a good idea to keep. > (to load monticello). Yes I thought the same when I looked at them and comparing with Pharo40. But after I could not find why we lost menu items but I was wrong. I think that this is just one single and simple package so we can keep it for now. > Marcus > > > >

Sept. 6, 2015

Re: [Pharo-dev] remove MczInstaller?

by stepharo

Thanks a lot martin! I checked also and I got confused :) I have to investigate more. Could you open a bug entry because this is handy to be able to browse an mcz by dropping it on the world My impression is that we could remove MCMcmReader class MCMcdReader class Le 5/9/15 19:00, Martin Dias a Ã©crit : > Hi, > > I logged for which classes MCVersionReader >> > fileReaderServicesForFile:suffix: is invoked: > > In Pharo 4: > > MCVersionReader class > MCMczReader class > MCMcmReader class > MCMcdReader class > > In Pharo 5: > > MCVersionReader class > > > and it should be MCMczReader who adds those services for the MCZ files. > > Note: I tried in Pharo 4, and the list of file services didn't change > after removing MczInstaller. > > > > > > MartÃn > > On Sat, Sep 5, 2015 at 6:24 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> On 05 Sep 2015, at 15:54, stepharo <stepharo(a)free.fr> wrote: >>> >>> Are you sure that it is not used when we drag an MCZ on the desktop? >> No, at least I do not think so. >> >> itâs the installer that was added to Squeak before Monticello. The idea is that it can be used >> to install .mzc files even when Monticello is not there. >> >> I was thinking of removing it in the past, but for a real modular system it might be a good idea to keep. >> (to load monticello). >> >> Marcus >> >> >> >

Sept. 6, 2015

chunk file format (unrecoverable changes)

by Nicolai Hess

Do we have a documentation about the format of - class definitions - methods - class comments for the changes file ? I am asking because some entries are using two separator "! !" and some only one "!" And we have a problem with the "Recover lost changes" browser (https://pharo.fogbugz.com/f/cases/16498/unrecoverable-changes) and I am not sure if this is a bug on the code importer or if it is a bug on how we write changes to the changes file. nicolai

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by stepharo

What I would like is to have all the changes after one integration with + and - showing the changes. I grouped a bit my analysis in https://pharo.fogbugz.com/f/cases/16491/Revisiting-TextDiffBuilder But now I should finish the other tasks I have pending. I should finish also some issues I started around announcers. Stef Le 6/9/15 15:50, Peter UhnÃ¡k a Ã©crit : > But this is all implementation details, I'm still not sure what > exactly we (Stef) want to send. > > * change diff after each successful CI build for an issue? > * diff after the change has been integrated? > > Peter

Sept. 6, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 6, 2015

[pharo-project/pharo-core] b9b044: 50309

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b9b04483fa5c00b4ca24f703cd877a066afa8d08 https://github.com/pharo-project/pharo-core/commit/b9b04483fa5c00b4ca24f703… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-06 (Sun, 06 Sep 2015) Changed paths: A Kernel.package/CompiledMethod.class/instance/accessing-pragmas %26 properties/hasProperty_.st M Reflectivity-Tests.package/CoverageDemoTest.class/instance/tests/testCoverageControlFlow.st M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkInPrimitive.st M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkOnPrimitive.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeMethodPrimitive.st M Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - primitives/testPrimitiveWithLinkExecuteWrapper.st M Reflectivity.package/ReflectiveMethod.class/instance/evaluation/generatePrimitiveWrapper.st M Reflectivity.package/ReflectiveMethod.class/instance/invalidate/destroyTwin.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50308.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50309.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50308.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50309.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50309 16499 Reflectivity and Primitive: Unwrap when destroying Twin, copy over links to wrapper https://pharo.fogbugz.com/f/cases/16499 http://files.pharo.org/image/50/50309.zip

Sept. 6, 2015

Re: [Pharo-dev] Low traffic [ANN] only list

by Marcus Denker

> On 06 Sep 2015, at 16:43, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Subscribing is quite cumbersome. > > 1. subscribe > 2. confirm my subscription > 3. confirm my humanity > > why not just the first? This could discourage people easily midway. > Ok, I have turned 3) off. Marcus

Sept. 6, 2015

Re: [Pharo-dev] Low traffic [ANN] only list

by Peter UhnÃ¡k

Subscribing is quite cumbersome. 1. subscribe 2. confirm my subscription 3. confirm my humanity why not just the first? This could discourage people easily midway. Peter On Sun, Sep 6, 2015 at 4:32 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > We have set up a low traffic announce-only list: > > http://eepurl.com/byhgL9 > > > The idea is that this is max one mail per month. > > Marcus >

Sept. 6, 2015

Low traffic [ANN] only list

by Marcus Denker

Hello, We have set up a low traffic announce-only list: http://eepurl.com/byhgL9 <http://eepurl.com/byhgL9> The idea is that this is max one mail per month. Marcus

Sept. 6, 2015

Re: [Pharo-dev] Rubric #mouseDown, #mouseUp and #click

by Stephan Eggermont

On 06/09/15 11:11, Nicolai Hess wrote: > Does the mouseUp on JobProgressMorph work ? > I always wondered how I can stop a long running task. I don't know. Not when running tests from the TestRunner. Stephan

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Peter UhnÃ¡k

But this is all implementation details, I'm still not sure what exactly we (Stef) want to send. * change diff after each successful CI build for an issue? * diff after the change has been integrated? Peter

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Peter UhnÃ¡k

> > You are right, Peter. But the way the rest of the world (and many people > using git from Pharo or other Smalltalk implementations) is that you > propose patches which I believe are quite similar to commits. That would be > the equivalent of our slice, I guess. I don't think that slice has equivalence in git, because we have changes much more fine-grained. Git patch is simply a diff between two different versions. And even though github (or bitbucket) offer things like "pull requests", they are only a nicer way of presenting a diff. But this doesn't really matter, because the result will be still the same. Now what might be an interesting work flow would be when an issue is tagged > Fix Review Needed and the CI monkey validates the issue it pushes the slice > to a new IssueNNNNN branch in github and branch diff emailed from there. Unless we want to migrate from fogzbugz to github and do code-reviews there in pull requests there's really no reason to create new branches. You can just create detached commits. (But then again, creating branches is dirt cheap). Actually for a diff you don't need to even commit, because you can compare your current code to the commited one (just like in Monticello). Peter

Sept. 6, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 6, 2015

[pharo-project/pharo-core] 56e3cc: 50308

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 56e3cce6d903a8bdca1427aad2d90eb15627d7e6 https://github.com/pharo-project/pharo-core/commit/56e3cce6d903a8bdca1427aa… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-06 (Sun, 06 Sep 2015) Changed paths: A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkInPrimitive.st M Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - links/testSetLinkOnPrimitive.st A Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - primitives/testPrimitiveWithLinkExecuteWrapper.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitMethodNode_.st M Reflectivity.package/ReflectiveMethod.class/instance/evaluation/compileAndInstallCompiledMethod.st A Reflectivity.package/ReflectiveMethod.class/instance/evaluation/generatePrimitiveWrapper.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50307.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50308.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50307.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50308.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-System.package/SystemSystemSettings.class/class/settings/systemSettingOn_.st Log Message: ----------- 50308 16495 Reflectivity: Wrap primitive methods https://pharo.fogbugz.com/f/cases/16495 16039 put a space between numbers and units https://pharo.fogbugz.com/f/cases/16039 http://files.pharo.org/image/50/50308.zip

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Ben Coman

On 6 Sep 2015 7:42 am, "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> wrote: >> >> git clone https://github.com/pharo-project/pharo-core.git >> cd pharo-core/ >> git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 > > > But this is post-integration, we want to review things before they break something, not after. > So ideally monkey reviews code on CI and if it passes the diff is sent from CI to the mailing list. > > Also these commits combine several unrelated issues, which is not good for review. > > Isn't what Squeak uses open-source and available somewhere? Can't we just reuse it? I thought the Squeak email diffs were post-commit?? Now what might be an interesting work flow would be when an issue is tagged Fix Review Needed and the CI monkey validates the issue it pushes the slice to a new IssueNNNNN branch in github and branch diff emailed from there. Cheers ben

Sept. 6, 2015

Re: [Pharo-dev] Rubric #mouseDown, #mouseUp and #click

by Nicolai Hess

Does the mouseUp on JobProgressMorph work ? I always wondered how I can stop a long running task. 2015-09-02 12:25 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > We have a few morphs where #on:#mouseDown send: aMessage to: aTarget is > used where I'd expected that to be on #click. Mostly in Rubric and the > Nautilus annotations > > If a morph is supposed to behave as a button, the action should happen > on the #mouseUp, but only if the mouse pointer hasn't moved away from > the morph. That is what #click does. > > And > ExpanderTitleMorph > GrowlMorph > JobProgressMorph > react on #mouseUp instead of #click > > Stephan > > >

Sept. 6, 2015

Nautilus strange pattern

by stepharo

Hi I'm trying to understand what there is a need for this window ifNil: [^ self ] And I wonder is this is not problem due to a global announcer that would keep announcer even when the nautilus widget has been deleted. Any other suggestions? Stef classRemoved: anAnnouncement | class oldPackage | window ifNil: [ ^ self ]. window isDisplayed ifFalse: [ ^ self ]. class := anAnnouncement classRemoved. (self classWidget getClassesList includes: class) ifTrue: [ classRecategorized: anAnnouncement window ifNil: [ ^ self ]. window isDisplayed ifFalse: [ ^ self ]. self selectedPackage ifNotNil:[:selection | ({ anAnnouncement oldCategory. anAnnouncement newCategory } anySatisfy: [ :each | selection includesCategory: each ]) ifTrue: [ self updatePackageGroupAndClassList ]] classRemoved: anAnnouncement | class oldPackage | window ifNil: [ ^ self ]. window isDisplayed ifFalse: [ ^ self ]. class := anAnnouncement classRemoved. (self classWidget getClassesList includes: cla

Sept. 6, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by stepharo

Le 5/9/15 22:42, Tudor Girba a Ã©crit : > +1. > > We already deprecated on:send:to:/on:do: and I think we should do the > same for the subscribe:send:to:. Thanks Doru. I thought the same. Because each time I read subscribe: my mind stops for about half or a second until I remember that this is the same as when: send: to: > > Doru > > On Sat, Sep 5, 2015 at 10:24 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > in announcer we have > > when: anAnnouncementClass send: aSelector to: anObject > "Declare that when anAnnouncementClass is raised, anObject > should receive the message aSelector. > When the message expects one argument (eg #fooAnnouncement:) > the announcement is passed as argument. > When the message expects two arguments (eg > #fooAnnouncement:announcer:) both the announcement and the announcer > are passed as argument" > > ^ self subscribe: anAnnouncementClass send: aSelector to: anObject > > > could we reduce the cognitive load and make sure that the API is > only one protocol for example when: send: to:? > I found it confusing and I have to check that this is indeed the same. > I think that having one way is far enough. > > What do you think? > Stef > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Tudor Girba

Hi, There is clearly no downside of having more detailed diff information available. We do not have it now, and the proposal of Stef is more than reasonable. It would be great to have someone willing to spend a bit of time helping him to achieve this. Who would like to give this a try? Cheers, Doru On Sun, Sep 6, 2015 at 10:28 AM, stepharo <stepharo(a)free.fr> wrote: > > > Le 6/9/15 00:33, Sven Van Caekenberghe a Ã©crit : > >> On 05 Sep 2015, at 21:34, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>> >>> Le 5/9/15 19:18, Yuriy Tymchuk a Ã©crit : >>> >>>> In fact you couldnât spot the issue by just looking at the patch :) >>>> there was a very strange thing that could be fixed with one line, but to >>>> identify it Iâve spent probably 1.5 hours :) >>>> >>> sure this is not my point. >>> my point is that we need to be able to know what changed. Right now I >>> see a title and I do not have the time to click on each github link. >>> I want to see diffs right in front of my nose. >>> >> I know very little about git, but the first thing that I tried worked: >> >> git clone https://github.com/pharo-project/pharo-core.git >> cd pharo-core/ >> git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 >> > > I went to github. > I do not want to have to type the hash and this. > How do I know that this this hash corresponds to the fixes that have been > submitted? > > Then the output is ***awful***. > So if this is that easy why can we have a mail with the diff? > > Stef > > > > > >> I assume that we could put that textual information in the mail. >> >> In my terminal, it is coloured, but I still think that the github page is >> much better: >> >> >> https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… >> >> (It happens that this commit changed quite a lot) >> >> Stef >>> >>>> Uko >>>> >>>> On 05 Sep 2015, at 19:03, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>> >>>>> >>>>> >>>>> 2015-09-05 11:48 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >>>>> >>>>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr> wrote: >>>>>> >>>>>> How can I see the changes? >>>>>> Our process is not good. Most of us do not get any chance >>>>>> understanding what is changing. >>>>>> >>>>>> -> download the image before it was added >>>>> -> merge the slice. >>>>> >>>>> Yes, our process is not goodâ¦ but from a review perspective, this >>>>> issue is the best we can do. >>>>> *two* reviews, both from people actively contributing to exactly that >>>>> part of the system. >>>>> >>>>> If we require more, we will be back at a process where due to Fear we >>>>> do nothing. >>>>> >>>>> >>>>> Nautilus is a difficult beast, you all know. Even if you look close at >>>>> the merge diff you may >>>>> miss some important relation that only really visible during debugging. >>>>> I did some test when reviewing this fix. But really, there are so many >>>>> ways do you need to consider >>>>> - different ways for opening nautilus >>>>> - navigate with keys and mouse >>>>> - selecting updating / changes from other browser and system changes. >>>>> - refactorings >>>>> >>>>> It is really not that easy and I am happy that Franck and Yuri are >>>>> actually trying to >>>>> improve Nautilus. >>>>> you can not easily tests all and make the changes and reviews bullet >>>>> proof. >>>>> >>>>> >>>>> nicolai >>>>> >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>>> >>>>>>> This is a side effect of >>>>>>> >>>>>>> >>>>>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… >>>>>>> >>>>>>> (which was reviewed by two people, so not obvious). >>>>>>> >>>>>>> What happened is that #updatePackageGroupAndClassList calls itself >>>>>>> via #selectedClass: leading to a loop. >>>>>>> >>>>>>> Should be easy to fix for the people involved in case 16475. >>>>>>> >>>>>>> Marcus >>>>>>> >>>>>>> >>>>>>> On Sat, Sep 5, 2015 at 8:51 AM, stepharo <stepharo(a)free.fr> wrote: >>>>>>> Hi >>>>>>> >>>>>>> I do not know if this is linked to recent changes but we cannot >>>>>>> remove classes or move them to another package. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Marcus Denker -- denker(a)acm.org >>>>>>> http://www.marcusdenker.de >>>>>>> >>>>>> >> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by stepharo

Le 6/9/15 00:33, Sven Van Caekenberghe a Ã©crit : >> On 05 Sep 2015, at 21:34, stepharo <stepharo(a)free.fr> wrote: >> >> >> >> Le 5/9/15 19:18, Yuriy Tymchuk a Ã©crit : >>> In fact you couldnât spot the issue by just looking at the patch :) there was a very strange thing that could be fixed with one line, but to identify it Iâve spent probably 1.5 hours :) >> sure this is not my point. >> my point is that we need to be able to know what changed. Right now I see a title and I do not have the time to click on each github link. >> I want to see diffs right in front of my nose. > I know very little about git, but the first thing that I tried worked: > > git clone https://github.com/pharo-project/pharo-core.git > cd pharo-core/ > git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 I went to github. I do not want to have to type the hash and this. How do I know that this this hash corresponds to the fixes that have been submitted? Then the output is ***awful***. So if this is that easy why can we have a mail with the diff? Stef > > I assume that we could put that textual information in the mail. > > In my terminal, it is coloured, but I still think that the github page is much better: > > https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… > > (It happens that this commit changed quite a lot) > >> Stef >>> Uko >>> >>>> On 05 Sep 2015, at 19:03, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>> >>>> >>>> >>>> 2015-09-05 11:48 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >>>> >>>>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> How can I see the changes? >>>>> Our process is not good. Most of us do not get any chance understanding what is changing. >>>>> >>>> -> download the image before it was added >>>> -> merge the slice. >>>> >>>> Yes, our process is not goodâ¦ but from a review perspective, this issue is the best we can do. >>>> *two* reviews, both from people actively contributing to exactly that part of the system. >>>> >>>> If we require more, we will be back at a process where due to Fear we do nothing. >>>> >>>> >>>> Nautilus is a difficult beast, you all know. Even if you look close at the merge diff you may >>>> miss some important relation that only really visible during debugging. >>>> I did some test when reviewing this fix. But really, there are so many >>>> ways do you need to consider >>>> - different ways for opening nautilus >>>> - navigate with keys and mouse >>>> - selecting updating / changes from other browser and system changes. >>>> - refactorings >>>> >>>> It is really not that easy and I am happy that Franck and Yuri are actually trying to >>>> improve Nautilus. >>>> you can not easily tests all and make the changes and reviews bullet proof. >>>> >>>> >>>> nicolai >>>> >>>> >>>> >>>>>> Hi, >>>>>> >>>>>> This is a side effect of >>>>>> >>>>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… >>>>>> >>>>>> (which was reviewed by two people, so not obvious). >>>>>> >>>>>> What happened is that #updatePackageGroupAndClassList calls itself via #selectedClass: leading to a loop. >>>>>> >>>>>> Should be easy to fix for the people involved in case 16475. >>>>>> >>>>>> Marcus >>>>>> >>>>>> >>>>>> On Sat, Sep 5, 2015 at 8:51 AM, stepharo <stepharo(a)free.fr> wrote: >>>>>> Hi >>>>>> >>>>>> I do not know if this is linked to recent changes but we cannot remove classes or move them to another package. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> -- >>>>>> Marcus Denker -- denker(a)acm.org >>>>>> http://www.marcusdenker.de > >

Sept. 6, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 6, 2015

[pharo-project/pharo-core] 96f3ce: 50307

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 96f3ceffe16fa3c72e2ba9e7c7590e00118c4d2f https://github.com/pharo-project/pharo-core/commit/96f3ceffe16fa3c72e2ba9e7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-06 (Sun, 06 Sep 2015) Changed paths: M AST-Core.package/RBParser.class/instance/accessing/parseExpression_.st M AST-Core.package/RBParser.class/instance/accessing/parseMethod_.st M AST-Core.package/RBParser.class/instance/private-parsing/parseBlock.st A AST-Core.package/RBParser.class/instance/private-parsing/parseIncompleteExpression_.st M AST-Core.package/RBParser.class/instance/private-parsing/parseVariableNode.st M AST-Core.package/RBScanner.class/instance/accessing/scanToken.st M AST-Core.package/RBScanner.class/instance/private-scanning/scanLiteral.st M AST-Core.package/RBScanner.class/instance/private-scanning/scanLiteralString.st M AST-Core.package/RBScanner.class/instance/private-scanning/stripComment.st M Morphic-Base.package/EmbeddedMenuMorph.class/instance/keyboard control/moveSelectionDown_event_.st M Morphic-Base.package/MenuItemMorph.class/instance/accessing/hasIconOrMarker.st M Morphic-Base.package/MenuItemMorph.class/instance/accessing/hasMarker.st M Morphic-Base.package/MenuItemMorph.class/instance/events/themeChanged.st M Morphic-Base.package/MenuItemMorph.class/instance/grabbing/aboutToBeGrabbedBy_.st M Morphic-Base.package/MenuItemMorph.class/instance/meta actions/wantsHaloFromClick.st M Morphic-Base.package/MenuItemMorph.class/instance/nil/deselectItem.st A Morphic-Base.package/MenuItemMorph.class/instance/testing/isMenuItemMorph.st A Morphic-Base.package/MenuLineMorph.class/instance/testing/isMenuLineMorph.st R Morphic-Base.package/MenuMorph.class/instance/accessing/hasItems.st R Morphic-Base.package/MenuMorph.class/instance/accessing/hasSubMenu_.st M Morphic-Base.package/MenuMorph.class/instance/accessing/items.st M Morphic-Base.package/MenuMorph.class/instance/accessing/lastItem.st M Morphic-Base.package/MenuMorph.class/instance/accessing/menuItems.st M Morphic-Base.package/MenuMorph.class/instance/accessing/popUpOwner.st M Morphic-Base.package/MenuMorph.class/instance/actions/deleteIfPopUp.st A Morphic-Base.package/MenuMorph.class/instance/construction-UIManager/addItem.st A Morphic-Base.package/MenuMorph.class/instance/construction-UIManager/addTitle.st M Morphic-Base.package/MenuMorph.class/instance/construction-title/addStayUpIcons.st R Morphic-Base.package/MenuMorph.class/instance/construction-title/newTitleIconCalling_form_ballonText_.st A Morphic-Base.package/MenuMorph.class/instance/construction-title/newTitleIconCalling_form_helpText_.st M Morphic-Base.package/MenuMorph.class/instance/construction/addAllFrom_.st M Morphic-Base.package/MenuMorph.class/instance/construction/addLine.st M Morphic-Base.package/MenuMorph.class/instance/construction/addMenuItem_.st M Morphic-Base.package/MenuMorph.class/instance/construction/addToggle_target_selector_getStateSelector_enablementSelector_argumentList_.st M Morphic-Base.package/MenuMorph.class/instance/initialization/initialize.st M Morphic-Base.package/MenuMorph.class/instance/invoking/informUserAt_during_.st M Morphic-Base.package/MenuMorph.class/instance/keyboard control/displayFiltered_.st M Morphic-Base.package/MenuMorph.class/instance/keyboard control/moveSelectionDown_event_.st M Morphic-Base.package/MenuMorph.class/instance/menu/addCustomMenuItems_hand_.st R Morphic-Base.package/MenuMorph.class/instance/menu/addItem.st R Morphic-Base.package/MenuMorph.class/instance/menu/addTitle.st M Morphic-Base.package/MenuMorph.class/instance/menu/detachSubMenu_.st M Morphic-Base.package/MenuMorph.class/instance/menu/doButtonAction.st M Morphic-Base.package/MenuMorph.class/instance/menu/removeStayUpItems.st M Morphic-Base.package/MenuMorph.class/instance/menu/setTarget_.st M Morphic-Base.package/MenuMorph.class/instance/menu/target_.st A Morphic-Base.package/MenuMorph.class/instance/submorphs-add%2Fremove/addMorphBack_.st A Morphic-Base.package/MenuMorph.class/instance/testing/hasItems.st A Morphic-Base.package/MenuMorph.class/instance/testing/hasSubMenu_.st A Morphic-Base.package/MenuMorph.class/instance/testing/isMenuMorph.st A Morphic-Base.package/extension/Morph/instance/isMenuItemMorph.st A Morphic-Base.package/extension/Morph/instance/isMenuLineMorph.st A Morphic-Base.package/extension/Morph/instance/isMenuMorph.st M Morphic-Base.package/extension/WorldState/class/windowsOn_.st M Polymorph-Widgets.package/IdentifierChooserMorph.class/instance/event handling/selectNextItem.st M Polymorph-Widgets.package/IdentifierChooserMorph.class/instance/event handling/selectPreviousItem.st M Polymorph-Widgets.package/IdentifierChooserMorph.class/instance/event handling/switchToOtherColumn_.st M Polymorph-Widgets.package/IdentifierChooserMorph.class/instance/ui-building/newChoicesMorph.st M Polymorph-Widgets.package/IdentifierChooserMorph.class/instance/ui-building/newMenuWith_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50306.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50307.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50306.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50307.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/MorphicMenuAdapter.class/instance/private/buildWidgetPopup.st M Tool-FileList.package/extension/MenuMorph/instance/addServices_for_extraLines_.st Log Message: ----------- 50307 16483 AST-Core should not depend on System-Localization https://pharo.fogbugz.com/f/cases/16483 16472 Minor improvements to MenuMorph (2) https://pharo.fogbugz.com/f/cases/16472 16492 no syntax highlighting if last expression is invalid code https://pharo.fogbugz.com/f/cases/16492 http://files.pharo.org/image/50/50307.zip

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by stepharo

Peter I just want to get an idea of what is happening. Even after commit. Le 6/9/15 01:41, Peter UhnÃ¡k a Ã©crit : > > git clone https://github.com/pharo-project/pharo-core.git > cd pharo-core/ > git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 > > > But this is post-integration, we want to review things before they > break something, not after. > So ideally monkey reviews code on CI and if it passes the diff is sent > from CI to the mailing list. > > Also these commits combine several unrelated issues, which is not good > for review. > > Isn't what Squeak uses open-source and available somewhere? Can't we > just reuse it? > > Peter

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Sven Van Caekenberghe

> On 06 Sep 2015, at 01:41, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > git clone https://github.com/pharo-project/pharo-core.git > cd pharo-core/ > git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 > > But this is post-integration, we want to review things before they break something, not after. > So ideally monkey reviews code on CI and if it passes the diff is sent from CI to the mailing list. > > Also these commits combine several unrelated issues, which is not good for review. > > Isn't what Squeak uses open-source and available somewhere? Can't we just reuse it? > > Peter You are right, Peter. But the way the rest of the world (and many people using git from Pharo or other Smalltalk implementations) is that you propose patches which I believe are quite similar to commits. That would be the equivalent of our slice, I guess. Sven

Sept. 6, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Tudor Girba

Probably yes. However, in that case the issue is at least internal to the implementation as nobody will actually use that class directly. Cheers, Doru On Sat, Sep 5, 2015 at 11:56 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > Excuse me, but what about the following messages > > MessageBrowser browse: > ({WeakSubscriptionBuilder>>#on:do:. > WeakSubscriptionBuilder>>#on:send:to:}) > > should be deprecated, or not? > > > > On Sat, Sep 5, 2015 at 5:24 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi >> >> in announcer we have >> >> when: anAnnouncementClass send: aSelector to: anObject >> "Declare that when anAnnouncementClass is raised, anObject should >> receive the message aSelector. >> When the message expects one argument (eg #fooAnnouncement:) the >> announcement is passed as argument. >> When the message expects two arguments (eg >> #fooAnnouncement:announcer:) both the announcement and the announcer >> are passed as argument" >> >> ^ self subscribe: anAnnouncementClass send: aSelector to: anObject >> >> >> could we reduce the cognitive load and make sure that the API is only one >> protocol for example when: send: to:? >> I found it confusing and I have to check that this is indeed the same. >> I think that having one way is far enough. >> >> What do you think? >> Stef >> >> > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 6, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Peter UhnÃ¡k

> > git clone https://github.com/pharo-project/pharo-core.git > cd pharo-core/ > git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 > But this is post-integration, we want to review things before they break something, not after. So ideally monkey reviews code on CI and if it passes the diff is sent from CI to the mailing list. Also these commits combine several unrelated issues, which is not good for review. Isn't what Squeak uses open-source and available somewhere? Can't we just reuse it? Peter

Sept. 5, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Sven Van Caekenberghe

> On 05 Sep 2015, at 21:34, stepharo <stepharo(a)free.fr> wrote: > > > > Le 5/9/15 19:18, Yuriy Tymchuk a Ã©crit : >> In fact you couldnât spot the issue by just looking at the patch :) there was a very strange thing that could be fixed with one line, but to identify it Iâve spent probably 1.5 hours :) > > sure this is not my point. > my point is that we need to be able to know what changed. Right now I see a title and I do not have the time to click on each github link. > I want to see diffs right in front of my nose. I know very little about git, but the first thing that I tried worked: git clone https://github.com/pharo-project/pharo-core.git cd pharo-core/ git show 2536752ecdd88e15b00c6d3e29cb055d108731c8 I assume that we could put that textual information in the mail. In my terminal, it is coloured, but I still think that the github page is much better: https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… (It happens that this commit changed quite a lot) > Stef >> >> Uko >> >>> On 05 Sep 2015, at 19:03, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>> >>> >>> 2015-09-05 11:48 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> How can I see the changes? >>>> Our process is not good. Most of us do not get any chance understanding what is changing. >>>> >>> >>> -> download the image before it was added >>> -> merge the slice. >>> >>> Yes, our process is not goodâ¦ but from a review perspective, this issue is the best we can do. >>> *two* reviews, both from people actively contributing to exactly that part of the system. >>> >>> If we require more, we will be back at a process where due to Fear we do nothing. >>> >>> >>> Nautilus is a difficult beast, you all know. Even if you look close at the merge diff you may >>> miss some important relation that only really visible during debugging. >>> I did some test when reviewing this fix. But really, there are so many >>> ways do you need to consider >>> - different ways for opening nautilus >>> - navigate with keys and mouse >>> - selecting updating / changes from other browser and system changes. >>> - refactorings >>> >>> It is really not that easy and I am happy that Franck and Yuri are actually trying to >>> improve Nautilus. >>> you can not easily tests all and make the changes and reviews bullet proof. >>> >>> >>> nicolai >>> >>> >>> >>>> >>>>> Hi, >>>>> >>>>> This is a side effect of >>>>> >>>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… >>>>> >>>>> (which was reviewed by two people, so not obvious). >>>>> >>>>> What happened is that #updatePackageGroupAndClassList calls itself via #selectedClass: leading to a loop. >>>>> >>>>> Should be easy to fix for the people involved in case 16475. >>>>> >>>>> Marcus >>>>> >>>>> >>>>> On Sat, Sep 5, 2015 at 8:51 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> Hi >>>>> >>>>> I do not know if this is linked to recent changes but we cannot remove classes or move them to another package. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Marcus Denker -- denker(a)acm.org >>>>> http://www.marcusdenker.de >> >

Sept. 5, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Bernardo Ezequiel Contreras

Excuse me, but what about the following messages MessageBrowser browse: ({WeakSubscriptionBuilder>>#on:do:. WeakSubscriptionBuilder>>#on:send:to:}) should be deprecated, or not? On Sat, Sep 5, 2015 at 5:24 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > in announcer we have > > when: anAnnouncementClass send: aSelector to: anObject > "Declare that when anAnnouncementClass is raised, anObject should > receive the message aSelector. > When the message expects one argument (eg #fooAnnouncement:) the > announcement is passed as argument. > When the message expects two arguments (eg > #fooAnnouncement:announcer:) both the announcement and the announcer > are passed as argument" > > ^ self subscribe: anAnnouncementClass send: aSelector to: anObject > > > could we reduce the cognitive load and make sure that the API is only one > protocol for example when: send: to:? > I found it confusing and I have to check that this is indeed the same. > I think that having one way is far enough. > > What do you think? > Stef > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Sept. 5, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by Ferlicot D. Cyril

Le 05/09/2015 21:39, stepharo a Ã©crit : > > > Le 5/9/15 16:49, Yuriy Tymchuk a Ã©crit : >> I can give you a short explanation for the sake of more people knowing >> how Nautilus works. > Yes please if you have some time. > What I do not like is that we pass nil to indicate that there is no > selection. I was thinking that an hierarchy of null objects could help > but this is difficult to > foresee if it will make sense. > I also that all the logic update without reselecting is complex. > I started to read the code and also move some condition about the model > to the model class :). > I would like to do just a simple pass reading all the code and not > changing much to get now yet another better feel of nautilus. > I will also remove the Nautilus help. > I would like to rename the NautilusRefactoring because it is not about > nautilus but about RB. > >> >> Regarding diffs and knowledge sharing, we should have a normal code >> review support with something like gerrit. > > thomas was working on a code review tool and skip is taking over so I > hope that we will have it. >> >> Uko >> > > I am also interesting for the informations about Nautilus :) Each time I try to check some code from it it's Hell! -- Cyril

Sept. 5, 2015

GroupAnnouncer?

by stepharo

Hi A final thought from my reading of Nautilus and related. I'm thinking that we could merge GroupAnnouncer into class side Group. Because I do not see the point to have a singleton and a subclass of Announcer. Stef

Sept. 5, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Tudor Girba

+1. We already deprecated on:send:to:/on:do: and I think we should do the same for the subscribe:send:to:. Doru On Sat, Sep 5, 2015 at 10:24 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > in announcer we have > > when: anAnnouncementClass send: aSelector to: anObject > "Declare that when anAnnouncementClass is raised, anObject should > receive the message aSelector. > When the message expects one argument (eg #fooAnnouncement:) the > announcement is passed as argument. > When the message expects two arguments (eg > #fooAnnouncement:announcer:) both the announcement and the announcer > are passed as argument" > > ^ self subscribe: anAnnouncementClass send: aSelector to: anObject > > > could we reduce the cognitive load and make sure that the API is only one > protocol for example when: send: to:? > I found it confusing and I have to check that this is indeed the same. > I think that having one way is far enough. > > What do you think? > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 5, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by stepharo

> I am confused till now I have been reading that pharo does not care > about the past or does not care about being another Smalltalk > implementation and it cares only being Smalltalk inspired . What > changed in the meant time ? Why so much talk about other Smalltalks > and ANSI-Smalltalk ? Nothing we do not diverge for the fun in general. We diverge to improve (of course people can discuss it and think that we are idiots) Now if adding a method in a package can help people porting to Pharo we should not be stupid :) Stef > > On Sat, Sep 5, 2015 at 6:28 AM Sean P. DeNigris <sean(a)clipperadams.com > <mailto:sean@clipperadams.com>> wrote: > > Ben Coman wrote > >>> Because the proper English spelling is with lowercase > > +1.... So it may be useful to have an ANSICompatibility package > > +1 to having the proper spelling (that we've fought so hard to > have) as the > only one in the image. And +1 for a compatibility package if there > is a > proven demand for such a thing. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Need-a-decision-on-subString-vs-substring-tp4847932p4… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. >

Sept. 5, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by stepharo

> > I agree with that. > To be compatible with these goals, I think my proposition just > needs to be updated a bit. > I'm still in favor of rules to transform ANSI code to Pharo code. > The point is that we should not force the user to update their > code base. The rule-cased approach is compatible with that if you > transform ANSI code when it gets loaded in the image. > > > True to a point. That point being folks who want to write code that > could play in other ANSI Smalltalks - with your approach, you have > locked those people out, since they CAN'T write ansi code - only Pharo > code. any non-Pharo ANSI'ism would be auto-changed back to Pharo - > and they'd leave to write and live in a different Smalltalk. > > Now, if you had the ANSI compatibility layer that either allowed > conversion to Pharo OR ignored conversion to Pharo, that wouldn't be a > barrier. > > On a different topic, what would be required to amend the ANSI > standard? Maybe a Smalltalk Agreement 2016 that took the standard and > amended some parts (like fixing the spelling) so that going forward, > all Smalltalks could be standard with good English spellings? Chris ANSI is not really good. It is old. And the time investement would be enormous to improve and nobody would care. I read it with attention about strings for example. Because the String API is not really nice in any Smalltalk but this is another story. I do not expect anything from Ansi or any improvements. Let us face it when VW change syntax, added namespaces or whatever they did not care about ANSI. So adding a compatibility package is the way to go. Stef

Sept. 5, 2015

when:send:to: vs. subscribe:send:to:

by stepharo

Hi in announcer we have when: anAnnouncementClass send: aSelector to: anObject "Declare that when anAnnouncementClass is raised, anObject should receive the message aSelector. When the message expects one argument (eg #fooAnnouncement:) the announcement is passed as argument. When the message expects two arguments (eg #fooAnnouncement:announcer:) both the announcement and the announcer are passed as argument" ^ self subscribe: anAnnouncementClass send: aSelector to: anObject could we reduce the cognitive load and make sure that the API is only one protocol for example when: send: to:? I found it confusing and I have to check that this is indeed the same. I think that having one way is far enough. What do you think? Stef

Sept. 5, 2015

Nautilus cleaning ideas.

by stepharo

Hi I was reading code and I was wondering if we could have a simple NullPlugin to avoid bottom := self model plugins select: [:each | each position = #bottom ]. bottom ifEmpty: [ ^ nil ]. and bottomMorph := self buildBottomPlugins. bottomMorph ifNotNil: [ bottomHeight := bottomMorph height + 8 ]. aWindow addMorph: sourceCodeContainer fullFrame: ((0 @ self navigationAreaProportion corner: 1 @ 1) asLayoutFrame topOffset: middleHeight; bottomOffset: bottomHeight negated). bottomMorph ifNotNil: [ aWindow addMorph: bottomMorph fullFrame: ((0 @ 1 corner: 1 @ 1) asLayoutFrame topOffset: bottomHeight negated). bottomMorph color: Color transparent ] But I do not think that this is the solution. Just brainstorming.... I imagine that we should change the computation to go from bottomMorph := self buildBottomPlugins. bottomMorph ifNotNil: [ bottomHeight := bottomMorph height + 8 ]. aWindow addMorph: sourceCodeContainer fullFrame: ((0 @ self navigationAreaProportion corner: 1 @ 1) asLayoutFrame topOffset: middleHeight; bottomOffset: bottomHeight negated). bottomMorph ifNotNil: [ aWindow addMorph: bottomMorph fullFrame: ((0 @ 1 corner: 1 @ 1) asLayoutFrame topOffset: bottomHeight negated). bottomMorph color: Color transparent ] into bottomMorph := self buildBottomPlugins. bottomHeight := bottomMorph height + 8. aWindow addMorph: sourceCodeContainer fullFrame: ((0 @ self navigationAreaProportion corner: 1 @ 1) asLayoutFrame topOffset: middleHeight; bottomOffset: bottomHeight negated). bottomMorph addYourselfInto: aWindow. and for the Null version height returns 0 addYourselfInto: does nothing. What do you think? Stef

Sept. 5, 2015

Re: [Pharo-dev] how do I push fixed upstream?

by Nicolai Hess

notify the maintainers 2015-09-05 20:51 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > How do I push "fixed upstream"? > > Since it doesn't have "Fix Review Needed" nobody will see it, review it > and merge it. How should I mark it? Do I need to make another step? > > > https://pharo.fogbugz.com/f/cases/15920/Cannot-inspect-a-SpecTreeNodeModel-… > > Peter >

Sept. 5, 2015

Re: [Pharo-dev] how do I push fixed upstream?

by Andrei Chis

To push it you need to make a version for that project. Then if that version only fixes a single bug you can put the issue on "fix review needed" and fill in the fields ConfigurationOf and ConfigurationVersion from the issue. Alternatively, if you need to integrate more issues, you can put those issues on fixed upstream and create a new issue that you put on "fix review needed", fill in ConfigurationOf and ConfigurationVersion and add in the description the issues that it addresses. For gtools we usually uses the second approach and integrate when there are 2-3 issues on fixed upstream. I can make a new version for glamour to integrate on monday (I'm travelling tomorrow) but if you want you can give it a try. Creating a new version for glamour with versioner should be easy :) Cheers, Andrei On Sat, Sep 5, 2015 at 8:51 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > How do I push "fixed upstream"? > > Since it doesn't have "Fix Review Needed" nobody will see it, review it > and merge it. How should I mark it? Do I need to make another step? > > > https://pharo.fogbugz.com/f/cases/15920/Cannot-inspect-a-SpecTreeNodeModel-… > > Peter >

Sept. 5, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by stepharo

Le 5/9/15 16:49, Yuriy Tymchuk a Ã©crit : > I can give you a short explanation for the sake of more people knowing how Nautilus works. Yes please if you have some time. What I do not like is that we pass nil to indicate that there is no selection. I was thinking that an hierarchy of null objects could help but this is difficult to foresee if it will make sense. I also that all the logic update without reselecting is complex. I started to read the code and also move some condition about the model to the model class :). I would like to do just a simple pass reading all the code and not changing much to get now yet another better feel of nautilus. I will also remove the Nautilus help. I would like to rename the NautilusRefactoring because it is not about nautilus but about RB. > > Regarding diffs and knowledge sharing, we should have a normal code review support with something like gerrit. thomas was working on a code review tool and skip is taking over so I hope that we will have it. > > Uko > >> On 05 Sep 2015, at 15:46, stepharo <stepharo(a)free.fr> wrote: >> >> As you wish. Thanks for your time. >> >> Now I will get really frustrated because I will not know simply what you did and I will have missed a good occasion >> to learn something. This is what sending the diff in text simply give us. >> >> Stef >> >> >> Le 5/9/15 14:09, Yuriy Tymchuk a Ã©crit : >>> I found the issue. Fix almost ready. Should I reopen the case, or create a new one? >>> >>> Uko >>> >>> >>> >>>> On 05 Sep 2015, at 13:59, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>> On 05-09-15 08:51, stepharo wrote: >>>>> Hi >>>>> >>>>> I do not know if this is linked to recent changes but we cannot remove >>>>> classes or move them to another package >>>> I can move them to another package using drag-and-drop (issue 16488) >>>> in 50305 >>>> >>>> >>>> Stephan >>>> >>>> >>> >> > >

Sept. 5, 2015

Re: [Pharo-dev] ***important*** cannot remove a class anymore...

by stepharo

Le 5/9/15 20:46, Peter UhnÃ¡k a Ã©crit : > Just because looking at a patch isn't as powerful doesn't make it > useless. There are still benefits > > * you are more aware of code changes > * you can still spot conceptual problems > * it's dead simple; the mail literally arrives at your doorsteps and > all you need to do is look > > of course this isn't replacing proper review, but there is big still > value in it. 100% what I want to say. I will allocate time on a goodies that take a slice and produce a diff > > But even the "regular" process could be improved. > >> -> download the image before it was added >> -> merge the slice. >> > For example I have startup script, that for images that have name > "issuenumber - verify" on startup automatically opens MCBrowser on the > slice so I can merge with two clicks. > (It's not automerged because I want to test behavior before and after > loading the slice.) > > Since I'm mostly verifying my own fixes, I generally don't look at the > changesets, but maybe you could autoopen a diff or something... > Or even add a category to PharoLauncher "Pharo - To Review" so I > wouldn't even need to type in the issue number. > > Peter

Sept. 5, 2015