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

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

by stepharo

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. Stef > > Uko > >> On 05 Sep 2015, at 19:03, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >> >> >> 2015-09-05 11:48 GMT+02:00 Marcus Denker<marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>>: >> >> >>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr >>> <mailto:stepharo@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 >>>> <mailto:stepharo@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 <mailto:denker@acm.org> >>>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >> >

Sept. 5, 2015

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

by stepharo

Oh yes I know. I'm not saying that looking at the changes we would have spotted the problems. I'm just saying that I want to get the changes in textual format in my mail-box as in squeak because it helps me understanding and knowing that something changed. I'm digging in the Diffbuilder and friends to see but I have some other tasks to finish first. > 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 >>> <mailto:stepharo@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 <mailto:denker@acm.org> >>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >> > >

Sept. 5, 2015

Re: [Pharo-dev] rb highlighting is not up to the task yet

by Tudor Girba

Great. I also think we should push in this direction. So, I will continue testing and provide feedback. Please ping me when you modify something. Ok? Cheers, Doru On Sat, Sep 5, 2015 at 9:15 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > I do, working with RBStyler makes much more fun than with the other one > and working > with AST instead of plain code text, gives us many possibilities to create > great tools (highlighter for example:) ) > > -> > pharo.fogbugz.com/f/cases/16492/no-syntax-highlighting-if-last-expression-i… > > I think we should not go back to the old one, but force the work on the rb > styler. > Just report any issues you see. > > > 2015-09-05 20:29 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Yes, indeed. I think it is already much better than it was some months >> ago, and I definitely think it is a great goal to have everything around RB. >> >> My question was only if there is anyone that invests in this actively >> because perhaps we can work together? >> >> Cheers, >> Doru >> >> >> >> On Sat, Sep 5, 2015 at 6:34 PM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >>> Hello, >>> >>> Yes, I am aware of that. >>> >>> The idea was to evaluate how good the RB AST colouring is already and >>> maybe find the energy to >>> fix all remaining problemsâ¦ we fixed many but not all. >>> >>> I propose that we keep it for some month more and if we donât improve >>> these problems go >>> back to the old scheme for Pharo5. >>> >>> Then we can re-start to work on this in Pharo6. >>> >>> >>> Marcus >>> >>> On 05 Sep 2015, at 07:28, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> Here is an example. >>> >>> Type this in a playground in a Pharo 5 image, and all statements before >>> the parentheses become black: >>> | a b c d | >>> a := 42. >>> b := a + 1. >>> c := b + 1. >>> d := c + 1. >>> a . b . c . d } >>> >>> <Playground-50.png> >>> >>> Here is how this looks in a Pharo 4: >>> >>> <Playground-40.png> >>> >>> Cheers, >>> Doru >>> >>> >>> On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <nicolaihess(a)web.de> >>> wrote: >>> >>>> This depends on the kind of error. For example, a missing open or >>>> closed parenthesis will most >>>> likely mark the whole (following) code. >>>> >>>> But it should still highlight the preceding code. >>>> Can you give an example. >>>> >>>> >>>> nicolai >>>> >>>> >>>> 2015-09-04 23:10 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>>> >>>>> Hi, >>>>> >>>>> I think it's nice that we are going towards consolidating our tools >>>>> around RB. >>>>> >>>>> However, the highlighting logic is not quite enough because if I have >>>>> an error anywhere in the code, the whole highlighting disappears. In >>>>> contrast, Shout manages to limit the problem only to the surrounding code. >>>>> >>>>> Is anyone working on this part of the highlighting? >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 5, 2015

Re: [Pharo-dev] rb highlighting is not up to the task yet

by Nicolai Hess

I do, working with RBStyler makes much more fun than with the other one and working with AST instead of plain code text, gives us many possibilities to create great tools (highlighter for example:) ) -> pharo.fogbugz.com/f/cases/16492/no-syntax-highlighting-if-last-expression-i… I think we should not go back to the old one, but force the work on the rb styler. Just report any issues you see. 2015-09-05 20:29 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Yes, indeed. I think it is already much better than it was some months > ago, and I definitely think it is a great goal to have everything around RB. > > My question was only if there is anyone that invests in this actively > because perhaps we can work together? > > Cheers, > Doru > > > > On Sat, Sep 5, 2015 at 6:34 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hello, >> >> Yes, I am aware of that. >> >> The idea was to evaluate how good the RB AST colouring is already and >> maybe find the energy to >> fix all remaining problemsâ¦ we fixed many but not all. >> >> I propose that we keep it for some month more and if we donât improve >> these problems go >> back to the old scheme for Pharo5. >> >> Then we can re-start to work on this in Pharo6. >> >> >> Marcus >> >> On 05 Sep 2015, at 07:28, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> Here is an example. >> >> Type this in a playground in a Pharo 5 image, and all statements before >> the parentheses become black: >> | a b c d | >> a := 42. >> b := a + 1. >> c := b + 1. >> d := c + 1. >> a . b . c . d } >> >> <Playground-50.png> >> >> Here is how this looks in a Pharo 4: >> >> <Playground-40.png> >> >> Cheers, >> Doru >> >> >> On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> This depends on the kind of error. For example, a missing open or closed >>> parenthesis will most >>> likely mark the whole (following) code. >>> >>> But it should still highlight the preceding code. >>> Can you give an example. >>> >>> >>> nicolai >>> >>> >>> 2015-09-04 23:10 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> >>>> Hi, >>>> >>>> I think it's nice that we are going towards consolidating our tools >>>> around RB. >>>> >>>> However, the highlighting logic is not quite enough because if I have >>>> an error anywhere in the code, the whole highlighting disappears. In >>>> contrast, Shout manages to limit the problem only to the surrounding code. >>>> >>>> Is anyone working on this part of the highlighting? >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Sept. 5, 2015

Re: [Pharo-dev] rb highlighting is not up to the task yet

by stepharo

+ 1 We cannot be improving all fronts in parallel. Stef Le 5/9/15 18:34, Marcus Denker a Ã©crit : > Hello, > > Yes, I am aware of that. > > The idea was to evaluate how good the RB AST colouring is already and > maybe find the energy to > fix all remaining problemsâ¦ we fixed many but not all. > > I propose that we keep it for some month more and if we donât improve > these problems go > back to the old scheme for Pharo5. > > Then we can re-start to work on this in Pharo6. > > > Marcus > >> On 05 Sep 2015, at 07:28, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >> Here is an example. >> >> Type this in a playground in a Pharo 5 image, and all statements >> before the parentheses become black: >> | a b c d | >> a := 42. >> b := a + 1. >> c := b + 1. >> d := c + 1. >> a . b . c . d } >> >> <Playground-50.png> >> >> Here is how this looks in a Pharo 4: >> >> <Playground-40.png> >> >> Cheers, >> Doru >> >> >> On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >> This depends on the kind of error. For example, a missing open or >> closed parenthesis will most >> likely mark the whole (following) code. >> >> But it should still highlight the preceding code. >> Can you give an example. >> >> >> nicolai >> >> >> 2015-09-04 23:10 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>>: >> >> Hi, >> >> I think it's nice that we are going towards consolidating our >> tools around RB. >> >> However, the highlighting logic is not quite enough because >> if I have an error anywhere in the code, the whole >> highlighting disappears. In contrast, Shout manages to limit >> the problem only to the surrounding code. >> >> Is anyone working on this part of the highlighting? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" >

Sept. 5, 2015

how do I push fixed upstream?

by Peter UhnÃ¡k

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 Peter UhnÃ¡k

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. 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

Re: [Pharo-dev] rb highlighting is not up to the task yet

by Tudor Girba

Hi, Yes, indeed. I think it is already much better than it was some months ago, and I definitely think it is a great goal to have everything around RB. My question was only if there is anyone that invests in this actively because perhaps we can work together? Cheers, Doru On Sat, Sep 5, 2015 at 6:34 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > Yes, I am aware of that. > > The idea was to evaluate how good the RB AST colouring is already and > maybe find the energy to > fix all remaining problemsâ¦ we fixed many but not all. > > I propose that we keep it for some month more and if we donât improve > these problems go > back to the old scheme for Pharo5. > > Then we can re-start to work on this in Pharo6. > > > Marcus > > On 05 Sep 2015, at 07:28, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Here is an example. > > Type this in a playground in a Pharo 5 image, and all statements before > the parentheses become black: > | a b c d | > a := 42. > b := a + 1. > c := b + 1. > d := c + 1. > a . b . c . d } > > <Playground-50.png> > > Here is how this looks in a Pharo 4: > > <Playground-40.png> > > Cheers, > Doru > > > On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> This depends on the kind of error. For example, a missing open or closed >> parenthesis will most >> likely mark the whole (following) code. >> >> But it should still highlight the preceding code. >> Can you give an example. >> >> >> nicolai >> >> >> 2015-09-04 23:10 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >>> Hi, >>> >>> I think it's nice that we are going towards consolidating our tools >>> around RB. >>> >>> However, the highlighting logic is not quite enough because if I have an >>> error anywhere in the code, the whole highlighting disappears. In contrast, >>> Shout manages to limit the problem only to the surrounding code. >>> >>> Is anyone working on this part of the highlighting? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 5, 2015

Re: [Pharo-dev] how do I get the git commit diff

by Thierry Goubier

Le 05/09/2015 19:51, Skip a Ã©crit : > Short side note: monday I will give a presentation about a code > review tool for Pharo I will work on as an intern at rmod. Itâs > called Griotte and there has already been some work done on it by > Thomas, a previous intern. We will hold a discussion afterwards. > > Maybe doing something with e-mails is a good idea as well (for > example when someone replies on a change). I will put it in the > presentation so that we can discuss this together. I think the seamless email to web and back implemented by github is very nice. > So stay tuned for monday. I see that this is a current problem, so > involving you in this project is a good idea (which is the reason for > my reply). > > I can send the slides to the mailing list afterwards. > > PS: for what itâs worth, when you comment to a diff in a pull request > on Github, you also get an e-mail with the relevant part of the > diff. PS: When you reply to that mail (or to an issue), then your email answer is integrated in the comments... so you can reply by mail instead of going to the web. Little features often matter a lot in such a workflow. Regards, Thierry

Sept. 5, 2015

Re: [Pharo-dev] how do I get the git commit diff

by Skip

Short side note: monday I will give a presentation about a code review tool for Pharo I will work on as an intern at rmod. Itâs called Griotte and there has already been some work done on it by Thomas, a previous intern. We will hold a discussion afterwards. Maybe doing something with e-mails is a good idea as well (for example when someone replies on a change). I will put it in the presentation so that we can discuss this together. So stay tuned for monday. I see that this is a current problem, so involving you in this project is a good idea (which is the reason for my reply). I can send the slides to the mailing list afterwards. PS: for what itâs worth, when you comment to a diff in a pull request on Github, you also get an e-mail with the relevant part of the diff.

Sept. 5, 2015

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

by Yuriy Tymchuk

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 :) 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 <mailto:marcus.denker@inria.fr>>: > >> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr <mailto:stepharo@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… <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 <mailto:stepharo@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 <mailto:denker@acm.org> >>> http://www.marcusdenker.de <http://www.marcusdenker.de/>

Sept. 5, 2015

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

by Nicolai Hess

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] remove MczInstaller?

by Martin Dias

On Sat, Sep 5, 2015 at 7:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > 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. > > > > I sent this email because I was starting to update the change of this method: useNewChangeSetDuring: aBlock | changeHolder oldChanges newChanges | changeHolder := (ChangeSet respondsTo: #newChanges:) ifTrue: [ChangeSet] ifFalse: [Smalltalk]. oldChanges := (ChangeSet respondsTo: #current) ifTrue: [ChangeSet current] ifFalse: [Smalltalk changes]. newChanges := ChangeSet new name: (ChangeSet uniqueNameLike: self extractPackageName). changeHolder newChanges: newChanges. [aBlock value] ensure: [changeHolder newChanges: oldChanges]. to just assume that ChangeSet can respond to those messages, and then I realized that there were no references to the whole class... MartÃn

Sept. 5, 2015

Re: [Pharo-dev] remove MczInstaller?

by Martin Dias

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. 5, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 5, 2015

[pharo-project/pharo-core] 948180: 50306

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9481809ccc4c7874fce2997bb202a34f35dc480f https://github.com/pharo-project/pharo-core/commit/9481809ccc4c7874fce2997b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-05 (Sat, 05 Sep 2015) Changed paths: M Nautilus.package/Nautilus.class/instance/accessing/selectedPackage_.st M Nautilus.package/PackageTreeNautilusUI.class/instance/private dispatch/registerSelectionPackage_.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterReturn.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadBlock.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadReturn.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitBlockNode_.st M Reflectivity.package/RFASTTranslator.class/instance/visitor-double dispatching/visitReturnNode_.st A Reflectivity.package/extension/RBReturnNode/instance/link_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50305.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50306.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50305.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50306.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot-Tests.package/SlotEnvironmentTest.class/instance/tests/testBasicEnvironment.st M Slot.package/PharoClassInstaller.class/instance/notifications/classAdded_inCategory_.st M System-Support.package/SystemDictionary.class/instance/accessing/organization.st Log Message: ----------- 50306 16485 Class panes not refreshed when changing package https://pharo.fogbugz.com/f/cases/16485 16479 Creating a class in an empty environment https://pharo.fogbugz.com/f/cases/16479 16481 #instead for Block https://pharo.fogbugz.com/f/cases/16481 http://files.pharo.org/image/50/50306.zip

Sept. 5, 2015

Re: [Pharo-dev] how do I get the git commit diff

by Dimitris Chloupis

the mail is not made for version control, github is. Why you would prefer a static way of doing things, from a very dynamic website ? When you commit to a github repo everyone that watches that repo , that is everyone that is either a contributor to that repo or a github user that has clicked the watch button will be alerted about everything related to that repo. The alerts appear in the front page of github.com when you log in. That includes commits, pull requests, new branches, issues, bugs, feature requests you name it. You could link that feed to your email so you get email alerts but personally I prefer keeping my email seperate from version controlling stuff. The advantages of github are too numerous to go in detail here, just read the github documentation. But to be put short, its easy to link towards other commits, you can comment commits , you can even comment specific lines of code (even using markdown ), and edit and commit on the fly using the website without opening pharo or git pulling to your local repo. Personally I would prefer to see a lot more pull requests because they are a very nice way to chain commits together and view them as one entity since they will concern the same matter. Pull requests also can be chained to issues and bug reports to mark the closed or open. What you list you refer to ? The link https://github.com/pharo-project/pharo-core/commit/8a1f79b44b14f8eafaf6d91a…, refers to a single commit with a ton of renamed files. You mean how you can get the list with the diff of each file changed ? thats easy, click on the commit. If you go to the repo for example here https://github.com/pharo-project/pharo-core/commits/4.0 clicking .... will expand the commit message but you if click on the commit itself will send you to the list of the diff log for that commit. Do you mean something else ? On Sat, Sep 5, 2015 at 10:02 AM stepharo <stepharo(a)free.fr> wrote: > Hi > > I still think that I would like in the squeak mailing-list to see the > diff of every commit by mail. > How can we enable that? Marcus you complain that not enough people are > active but we do not engage people by showing > changes. oh yes they can - by reading git commit.... oh boy if we > believe that people systematically have a look at that then > we are pretty naive. > > Now do not tell me that I can browse git commit I know it and this is > not what I need. > I need SYSTEMATIC awareness of a change. I NEED everybody to be able to > have look before deleting a mail. > It is working in Squeak. I can in my mail look at the changes. > > Or of course nobody cares in Pharo about changes and we can get regression. > > Another question: how can I get the list of links to git with the commit > logs like > > https://github.com/pharo-project/pharo-core/commit/8a1f79b44b14f8eafaf6d91a… > below? > How can I get the list? so that I can browse (I'm probably one of the > two few interested in fixing bugs after they got introduced). > > > Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core > Commit: 8a1f79b44b14f8eafaf6d91a8bab3c28e673114c > > https://github.com/pharo-project/pharo-core/commit/8a1f79b44b14f8eafaf6d91a… > > Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-04 > (Fri, 04 Sep 2015) > >

Sept. 5, 2015

Re: [Pharo-dev] rb highlighting is not up to the task yet

by Marcus Denker

Hello, Yes, I am aware of that. The idea was to evaluate how good the RB AST colouring is already and maybe find the energy to fix all remaining problemsâ¦ we fixed many but not all. I propose that we keep it for some month more and if we donât improve these problems go back to the old scheme for Pharo5. Then we can re-start to work on this in Pharo6. Marcus > On 05 Sep 2015, at 07:28, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Here is an example. > > Type this in a playground in a Pharo 5 image, and all statements before the parentheses become black: > | a b c d | > a := 42. > b := a + 1. > c := b + 1. > d := c + 1. > a . b . c . d } > > <Playground-50.png> > > Here is how this looks in a Pharo 4: > > <Playground-40.png> > > Cheers, > Doru > > > On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > This depends on the kind of error. For example, a missing open or closed parenthesis will most > likely mark the whole (following) code. > > But it should still highlight the preceding code. > Can you give an example. > > > nicolai > > > 2015-09-04 23:10 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: > Hi, > > I think it's nice that we are going towards consolidating our tools around RB. > > However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code. > > Is anyone working on this part of the highlighting? > > Cheers, > Doru > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Sept. 5, 2015

Re: [Pharo-dev] remove MczInstaller?

by Marcus Denker

> 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. 5, 2015

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

by Yuriy Tymchuk

I can give you a short explanation for the sake of more people knowing how Nautilus works. Regarding diffs and knowledge sharing, we should have a normal code review support with something like gerrit. 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] Need a decision on subString: vs substring:

by Dimitris Chloupis

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 ? On Sat, Sep 5, 2015 at 6:28 AM Sean P. DeNigris <sean(a)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] ***important*** cannot remove a class anymore...

by stepharo

>> On 05 Sep 2015, at 13:29, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> You can see changes for that patch here: >> https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… > YES, we have that for years now. and how many people read one change? > True, it is one click away, but the view is quite nice (not something that can be reproduced in an email). No it is not because I delete the mail with these headers and I cannot find a list on the web to find the diff. > >>> On 05 Sep 2015, at 13:23, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>>>> 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. >>> I do not want to require more. I want to see all the changes that we are doing without having to download an image >>> and doing merge. >>> I read many squeak changes like that and IT WORKS. >>> >>> Stef >>>>>> 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] remove MczInstaller?

by stepharo

When I drop an mcz file , in pharo 40 we got and in Pharo 50 Le 4/9/15 15:18, Martin Dias a Ã©crit : > Hi, > > Does somebody use MczInstaller to load Monticello files? The only > users in the image are it's tests. > > The class comment states: " > An installer for Monticello files with the *.mcz extension. > > MczInstaller installFileNamed: 'MyKillerApp-Core-Author.1.mcz' > " > > MartÃn

Sept. 5, 2015

now that we have a pragma for fileService

by stepharo

Hi now that we have a pragma for fileService description I imagine that the following method is not necessary anymore. Object class>>fileReaderServicesForFile: fullName suffix: suffix <fileService> "Backstop" ^#()

Sept. 5, 2015

Re: [Pharo-dev] remove MczInstaller?

by stepharo

Are you sure that it is not used when we drag an MCZ on the desktop? right now it is not working and we should address it (probably because we removed the duplication two copies of registration in different classes and we introduced a pragma). Le 4/9/15 15:18, Martin Dias a Ã©crit : > Hi, > > Does somebody use MczInstaller to load Monticello files? The only > users in the image are it's tests. > > The class comment states: " > An installer for Monticello files with the *.mcz extension. > > MczInstaller installFileNamed: 'MyKillerApp-Core-Author.1.mcz' > " > > MartÃn

Sept. 5, 2015

Re: [Pharo-dev] System announcements fixed?

by stepharo

Le 5/9/15 14:10, Stephan Eggermont a Ã©crit : > On 05-09-15 08:52, stepharo wrote: >> Since when? >> Where is the bug entry? >> Where is a reproducible case? > > The easy ones: > > 16485 Class panes not refreshed when changing package (by Marcus) > > 16486 Nautilus doesn't update the method pane after adding a method > (first time) > > 16487 Dropping methods on empty areas of class/method category pane > raises SubscriptOutOfBounds > > 16488 Dropping a class from one browser to another package in another > browser updates selected package+class in both > > 16489 Monticello browser doesn't update others after adding repo May be this is a ripple effect of the reducing the number of announcers that we started. We cannot get 50 different announcers in the systems. And may be we did not redo the initialization or something like that. Are the fixes of yuriy addressing the nautilus one? > > And there is a more difficult case where changing code in the debugger > does not get to (all) nautilus browsers. I had two browsers open and > changed code that was in the selected class but not visible in the > browsers. One browser was correctly updated, the other was not. > > This has happened for a few weeks now, and I thought this was known > and related to the current Nautilus refactorings. No Pharo is a complex system and we do not have enough tests. > > Stephan > > >

Sept. 5, 2015

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

by stepharo

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

> Ok, so the deepest Iâve got is that âself classWidget getClassesListâ > (where self is NautilusUI) always returns an empty list, so removed > class is not found in that list, so it is not removed from the model. > I have not changes ClassWidget and never worked with it, so from now > the investigation will go slower. Iâd appreciate help in any Nautilus > people are out there. this morning I started to read the method of AbstractNautilusUI now I still do not get what you did. I hate that I have to download a special image and merge a special slice. We should really have a diff in plain text as it is done in squeak sent to this mailing-list. With that it would take me less than a second to see what you were doing. Stef

Sept. 5, 2015

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

by Yuriy Tymchuk

Fix is under monkey validation: https://pharo.fogbugz.com/f/cases/16485/Class-panes-not-refreshed-when-chan… <https://pharo.fogbugz.com/f/cases/16485/Class-panes-not-refreshed-when-chan…> > On 05 Sep 2015, at 14:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 05 Sep 2015, at 13:29, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> You can see changes for that patch here: >> https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… > > YES, we have that for years now. > > True, it is one click away, but the view is quite nice (not something that can be reproduced in an email). > >>> On 05 Sep 2015, at 13:23, stepharo <stepharo(a)free.fr> wrote: >>> >>> >>>>> 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. >>> >>> I do not want to require more. I want to see all the changes that we are doing without having to download an image >>> and doing merge. >>> I read many squeak changes like that and IT WORKS. >>> >>> Stef >>>> >>>>> >>>>>> 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] ***important*** cannot remove a class anymore...

by Sven Van Caekenberghe

> On 05 Sep 2015, at 13:29, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > You can see changes for that patch here: > https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… YES, we have that for years now. True, it is one click away, but the view is quite nice (not something that can be reproduced in an email). >> On 05 Sep 2015, at 13:23, stepharo <stepharo(a)free.fr> wrote: >> >> >>>> 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. >> >> I do not want to require more. I want to see all the changes that we are doing without having to download an image >> and doing merge. >> I read many squeak changes like that and IT WORKS. >> >> Stef >>> >>>> >>>>> 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] ***important*** cannot remove a class anymore...

by Stephan Eggermont

On 05-09-15 14:09, Yuriy Tymchuk wrote: > I found the issue. Fix almost ready. Should I reopen the case, or create a new one? 16488 is a different issue Stephan

Sept. 5, 2015

Re: [Pharo-dev] System announcements fixed?

by Stephan Eggermont

On 05-09-15 08:52, stepharo wrote: > Since when? > Where is the bug entry? > Where is a reproducible case? The easy ones: 16485 Class panes not refreshed when changing package (by Marcus) 16486 Nautilus doesn't update the method pane after adding a method (first time) 16487 Dropping methods on empty areas of class/method category pane raises SubscriptOutOfBounds 16488 Dropping a class from one browser to another package in another browser updates selected package+class in both 16489 Monticello browser doesn't update others after adding repo And there is a more difficult case where changing code in the debugger does not get to (all) nautilus browsers. I had two browsers open and changed code that was in the selected class but not visible in the browsers. One browser was correctly updated, the other was not. This has happened for a few weeks now, and I thought this was known and related to the current Nautilus refactorings. Stephan

Sept. 5, 2015

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

by Yuriy Tymchuk

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 Stephan Eggermont

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 Yuriy Tymchuk

You can see changes for that patch here: https://github.com/pharo-project/pharo-core/commit/2536752ecdd88e15b00c6d3e… > On 05 Sep 2015, at 13:23, stepharo <stepharo(a)free.fr> wrote: > > >>> On 05 Sep 2015, at 11:40, stepharo < <mailto:stepharo@free.fr>stepharo(a)free.fr <mailto:stepharo@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. > > I do not want to require more. I want to see all the changes that we are doing without having to download an image > and doing merge. > I read many squeak changes like that and IT WORKS. > > Stef >> >>> >>>> Hi, >>>> >>>> This is a side effect of >>>> >>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <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 < <mailto:stepharo@free.fr>stepharo(a)free.fr <mailto:stepharo@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 <mailto:denker@acm.org> >>>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >>> >> >

Sept. 5, 2015

Re: [Pharo-dev] remove MczInstaller?

by stepharo

Hi martin how MCZ are then read? Stef Le 4/9/15 15:18, Martin Dias a Ã©crit : > Hi, > > Does somebody use MczInstaller to load Monticello files? The only > users in the image are it's tests. > > The class comment states: " > An installer for Monticello files with the *.mcz extension. > > MczInstaller installFileNamed: 'MyKillerApp-Core-Author.1.mcz' > " > > MartÃn

Sept. 5, 2015

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

by stepharo

>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr >> <mailto:stepharo@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. I do not want to require more. I want to see all the changes that we are doing without having to download an image and doing merge. I read many squeak changes like that and IT WORKS. Stef > >> >>> 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 >>> <mailto:stepharo@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 <mailto:denker@acm.org> >>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >> >

Sept. 5, 2015

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

by stepharo

This is my all point. I cannot help because I cannot see simply what you did. Le 5/9/15 13:07, Yuriy Tymchuk a Ã©crit : > Is there an easy way to browse a history of something. Or a blame > view? Because âbrowse versionsâ that is available in Nautilus shows > only the modifications in the current image. Having quick access to > the history can speedup things sooo much > >> On 05 Sep 2015, at 12:59, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >> <mailto:yuriy.tymchuk@me.com>> wrote: >> >> Iâm making progress. So the issue is that the selectedClass variable >> of Nautilus (model) is not set to nil when the class is being >> removed. I will check why. >> >>> On 05 Sep 2015, at 12:44, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >>> <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> As a side note: can we somehow write UI tests? Because this use-case >>> could be implemented as a test to ensure future auto checks. >>> >>> Uko >>> >>> >>>> On 05 Sep 2015, at 12:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >>>> <mailto:yuriy.tymchuk@me.com>> wrote: >>>> >>>> I will take a look now! >>>> >>>> >>>>> On 05 Sep 2015, at 11:48, Marcus Denker <marcus.denker(a)inria.fr >>>>> <mailto:marcus.denker@inria.fr>> wrote: >>>>> >>>>> >>>>>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr >>>>>> <mailto:stepharo@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. >>>>> >>>>>> >>>>>>> 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 >>>>>>> <mailto:stepharo@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 <mailto:denker@acm.org> >>>>>>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >>>>>> >>>>> >>>> >>> >> >

Sept. 5, 2015

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

by Yuriy Tymchuk

Ok, so the deepest Iâve got is that âself classWidget getClassesListâ (where self is NautilusUI) always returns an empty list, so removed class is not found in that list, so it is not removed from the model. I have not changes ClassWidget and never worked with it, so from now the investigation will go slower. Iâd appreciate help in any Nautilus people are out there. Uko > On 05 Sep 2015, at 12:59, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Iâm making progress. So the issue is that the selectedClass variable of Nautilus (model) is not set to nil when the class is being removed. I will check why. > >> On 05 Sep 2015, at 12:44, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> As a side note: can we somehow write UI tests? Because this use-case could be implemented as a test to ensure future auto checks. >> >> Uko >> >> >>> On 05 Sep 2015, at 12:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> I will take a look now! >>> >>> >>>> On 05 Sep 2015, at 11:48, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>>> >>>> >>>>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr <mailto:stepharo@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. >>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> This is a side effect of >>>>>> >>>>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <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 <mailto:stepharo@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 <mailto:denker@acm.org> >>>>>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >>>>> >>>> >>> >> >

Sept. 5, 2015

Re: [Pharo-dev] TextAttributes in source code or class comment?

by Nicolai Hess

The same for the ]lang[ tag (see issue 15750) 2015-09-05 12:06 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > Hi all > > On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman <btc(a)openinworld.com> wrote: > > On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > >> On Sep 4, 2015, at 1:33 PM, stepharo <stepharo(a)free.fr> wrote: > >> > >> Nobody defines urls in method comment anymore. > >> > >> I do. Several places in the Cog JIT contain irks to specification > >> documents. I don't care how its implemented (providing it's preserved > in > >> text, or maybe have the pretty-printer scan comments for http://. But > it is > >> sad that we can't have hyperlinks in text. > >> > >> Look I know the implementation stinks, but it can be fixed. But if the > >> functionality is lost the system is weakened. Instead of asking what > you > >> can get rid if why not ask what you can reimplement or enhance more > >> elegantly. > > > > Its a reasonable strategy to start the discussion at the extreme end > > and work back from there :) But if its being used we should think > > harder about it. What alternatives/workarounds are there? > > > > First just to clarify, the aim is to remove Text from the image for > > the boot-strap? > > Yes :) I heard that we want to do cut the dependency to Text-Core, so > I browsed how to do it. > > Ben, there is an explanation about ]style[ in the class comment of > RemoteString. > > Eliot, I didn't thought that somebody was using Text. In fact, I don't > know how to do it in Pharo... how do you do? > I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I > just tested filing-in the attached .st file and it doesn't work. I > guess the new CodeImporter replaced the ChangeRecord implementation, > and it raises an error when ]style[. > > MartÃn > > > > > > 1. Save the text internally as a string in the stream format and > > up-convert to Text only when its being displayed? But I guess these > > styles aren't restricted to just occurring in comments and maybe cause > > problem for compilation ?? > > > > 2. As a stepping stone, introduce a TextPlaceholder class within > > minimal interface required by compilation which simply strips out all > > styles when Text is missing from the Image. When Text is present it > > #becomes back to it. Maybe risks loosing styles editing is done on > > the raw-stream-format. Maybe any editor would show the raw ]style[ > > and the compiler asks for #source which strips styles out. > > > > 3. Introduce Pillar and convert across. What are the requirements? > > a. URLs > > b. Class/method links > > c. Would you expect that Pillar can only appear in comments? Or > > in-line with code? > > d. Colouring? > > ...? > > > > btw, I haven't come across this before. Can someone point me to some > > url & styled code where I can have a look at it > > > > cheers -ben > > > >> Christ you're even using minis paced fonts. It's like the dark > >> ages in there ;-) > >> > >> In addition would prefer to have an explicit syntax as in Pillar or > html to > >> represent > >> an hyperlink. We could have > >> *Class>>#method* when pillar is not loaded and else a nicer > >> representation. > >> ctrl-click on a class should jump on it already and we could map it to > >> *Class>>#method* > >> > >> In class comments we should use pillar and get a real text renderer. > >> > >> > >> Hi Martin, > >> > >> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias <tinchodias(a)gmail.com> > wrote: > >>> > >>> Hi all, > >>> > >>> The source code of a method could be a Text, with TextAttributes. In > such > >>> case, it will be written down to a stream with a "]style[" suffix. > Through a > >>> special parsing, the system can reconstruct the original Text. I think > the > >>> use of Text in source code or class comments is discouraged, but I > >>> understand we kept support for some backward compatibility. Now, may > be it's > >>> time to remove this feature. > >>> > >>> With Pablo, we looked for uses of ]style[ in the .sources and .changes > >>> files of a new Pharo 5.0, and there are no real uses. It appears in > some > >>> comments only, as examples. > >>> > >>> We tried to find past discussions about this feature, because we're > sure > >>> there were, but we couldn't. > >>> > >>> So, the questions is: > >>> > >>> Can we remove support for text in source code or class comments in > >>> Pharo 5.0? > >> > >> > >> IIUC, ]style[ also supports things like embedding URL links and method > >> references in class comments. So I would request that it /not/ be > removed. > >> It is very useful to put clickable links in class comments. > >> > >>> > >>> > >>> I think I can propose a slice. > >>> > >>> Regards, > >>> MartÃn > >>> PS: I was trying to cut dependencies of Text-Core with System-Changes > and > >>> System-Changes. > >> > >> > >> > >> > >> -- > >> _,,,^..^,,,_ > >> best, Eliot > >> > >> > > >

Sept. 5, 2015

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

by Marcus Denker

> On 05 Sep 2015, at 13:07, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Is there an easy way to browse a history of something. Or a blame view? Because âbrowse versionsâ that is available in Nautilus shows only the modifications in the current image. Having quick access to the history can speedup things sooo much > It should still show all changed done since the last condense of the sources/rewrite of the .sources. But yes, the âversionsâ that is not using the data from the revision control system is kind of uselessâ¦ Marcus

Sept. 5, 2015

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

by Yuriy Tymchuk

Is there an easy way to browse a history of something. Or a blame view? Because âbrowse versionsâ that is available in Nautilus shows only the modifications in the current image. Having quick access to the history can speedup things sooo much > On 05 Sep 2015, at 12:59, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Iâm making progress. So the issue is that the selectedClass variable of Nautilus (model) is not set to nil when the class is being removed. I will check why. > >> On 05 Sep 2015, at 12:44, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> As a side note: can we somehow write UI tests? Because this use-case could be implemented as a test to ensure future auto checks. >> >> Uko >> >> >>> On 05 Sep 2015, at 12:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> I will take a look now! >>> >>> >>>> On 05 Sep 2015, at 11:48, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>>> >>>> >>>>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr <mailto:stepharo@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. >>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> This is a side effect of >>>>>> >>>>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <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 <mailto:stepharo@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 <mailto:denker@acm.org> >>>>>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >>>>> >>>> >>> >> >

Sept. 5, 2015

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

by Yuriy Tymchuk

Iâm making progress. So the issue is that the selectedClass variable of Nautilus (model) is not set to nil when the class is being removed. I will check why. > On 05 Sep 2015, at 12:44, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > As a side note: can we somehow write UI tests? Because this use-case could be implemented as a test to ensure future auto checks. > > Uko > > >> On 05 Sep 2015, at 12:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> I will take a look now! >> >> >>> On 05 Sep 2015, at 11:48, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >>> >>> >>>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr <mailto:stepharo@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. >>> >>>> >>>>> Hi, >>>>> >>>>> This is a side effect of >>>>> >>>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <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 <mailto:stepharo@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 <mailto:denker@acm.org> >>>>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >>>> >>> >> >

Sept. 5, 2015

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

by Yuriy Tymchuk

As a side note: can we somehow write UI tests? Because this use-case could be implemented as a test to ensure future auto checks. Uko > On 05 Sep 2015, at 12:42, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > I will take a look now! > > >> On 05 Sep 2015, at 11:48, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> >>> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr <mailto:stepharo@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. >> >>> >>>> Hi, >>>> >>>> This is a side effect of >>>> >>>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <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 <mailto:stepharo@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 <mailto:denker@acm.org> >>>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >>> >> >

Sept. 5, 2015

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

by Yuriy Tymchuk

I will take a look now! > On 05 Sep 2015, at 11:48, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 05 Sep 2015, at 11:40, stepharo <stepharo(a)free.fr <mailto:stepharo@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. > >> >>> Hi, >>> >>> This is a side effect of >>> >>> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <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 <mailto:stepharo@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 <mailto:denker@acm.org> >>> http://www.marcusdenker.de <http://www.marcusdenker.de/> >> >

Sept. 5, 2015

Re: [Pharo-dev] TextAttributes in source code or class comment?

by Martin Dias

Hi all On Sat, Sep 5, 2015 at 3:44 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Sat, Sep 5, 2015 at 4:43 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> On Sep 4, 2015, at 1:33 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Nobody defines urls in method comment anymore. >> >> I do. Several places in the Cog JIT contain irks to specification >> documents. I don't care how its implemented (providing it's preserved in >> text, or maybe have the pretty-printer scan comments for http://. But it is >> sad that we can't have hyperlinks in text. >> >> Look I know the implementation stinks, but it can be fixed. But if the >> functionality is lost the system is weakened. Instead of asking what you >> can get rid if why not ask what you can reimplement or enhance more >> elegantly. > > Its a reasonable strategy to start the discussion at the extreme end > and work back from there :) But if its being used we should think > harder about it. What alternatives/workarounds are there? > > First just to clarify, the aim is to remove Text from the image for > the boot-strap? Yes :) I heard that we want to do cut the dependency to Text-Core, so I browsed how to do it. Ben, there is an explanation about ]style[ in the class comment of RemoteString. Eliot, I didn't thought that somebody was using Text. In fact, I don't know how to do it in Pharo... how do you do? I found that ChangeRecord>>fileIn uses #newTextChunk to parse, but I just tested filing-in the attached .st file and it doesn't work. I guess the new CodeImporter replaced the ChangeRecord implementation, and it raises an error when ]style[. MartÃn > > 1. Save the text internally as a string in the stream format and > up-convert to Text only when its being displayed? But I guess these > styles aren't restricted to just occurring in comments and maybe cause > problem for compilation ?? > > 2. As a stepping stone, introduce a TextPlaceholder class within > minimal interface required by compilation which simply strips out all > styles when Text is missing from the Image. When Text is present it > #becomes back to it. Maybe risks loosing styles editing is done on > the raw-stream-format. Maybe any editor would show the raw ]style[ > and the compiler asks for #source which strips styles out. > > 3. Introduce Pillar and convert across. What are the requirements? > a. URLs > b. Class/method links > c. Would you expect that Pillar can only appear in comments? Or > in-line with code? > d. Colouring? > ...? > > btw, I haven't come across this before. Can someone point me to some > url & styled code where I can have a look at it > > cheers -ben > >> Christ you're even using minis paced fonts. It's like the dark >> ages in there ;-) >> >> In addition would prefer to have an explicit syntax as in Pillar or html to >> represent >> an hyperlink. We could have >> *Class>>#method* when pillar is not loaded and else a nicer >> representation. >> ctrl-click on a class should jump on it already and we could map it to >> *Class>>#method* >> >> In class comments we should use pillar and get a real text renderer. >> >> >> Hi Martin, >> >> On Fri, Sep 4, 2015 at 8:13 AM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >>> Hi all, >>> >>> The source code of a method could be a Text, with TextAttributes. In such >>> case, it will be written down to a stream with a "]style[" suffix. Through a >>> special parsing, the system can reconstruct the original Text. I think the >>> use of Text in source code or class comments is discouraged, but I >>> understand we kept support for some backward compatibility. Now, may be it's >>> time to remove this feature. >>> >>> With Pablo, we looked for uses of ]style[ in the .sources and .changes >>> files of a new Pharo 5.0, and there are no real uses. It appears in some >>> comments only, as examples. >>> >>> We tried to find past discussions about this feature, because we're sure >>> there were, but we couldn't. >>> >>> So, the questions is: >>> >>> Can we remove support for text in source code or class comments in >>> Pharo 5.0? >> >> >> IIUC, ]style[ also supports things like embedding URL links and method >> references in class comments. So I would request that it /not/ be removed. >> It is very useful to put clickable links in class comments. >> >>> >>> >>> I think I can propose a slice. >>> >>> Regards, >>> MartÃn >>> PS: I was trying to cut dependencies of Text-Core with System-Changes and >>> System-Changes. >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> >

Sept. 5, 2015

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

by Marcus Denker

> 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. > >> Hi, >> >> This is a side effect of >> >> https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <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 <mailto:stepharo@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 <mailto:denker@acm.org> >> http://www.marcusdenker.de <http://www.marcusdenker.de/> >

Sept. 5, 2015

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

by stepharo

How can I see the changes? Our process is not good. Most of us do not get any chance understanding what is changing. > 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 > <mailto:stepharo@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 <mailto:denker@acm.org> > http://www.marcusdenker.de

Sept. 5, 2015

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

by Marcus Denker

> On 05 Sep 2015, at 09:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > This is a side effect of > > https://pharo.fogbugz.com/f/cases/16475/Nautilus-sends-too-many-announcemen… <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. I added an issue tracker entry: https://pharo.fogbugz.com/f/cases/16484/Endless-loop-on-refresh-after-delet… <https://pharo.fogbugz.com/f/cases/16484/Endless-loop-on-refresh-after-delet…> Marcus

Sept. 5, 2015

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

by Marcus Denker

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