- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Nov. 9, 2015

Re: [Pharo-dev] Woe unto thee who assigns to class-side #name!

by Sean P. DeNigris

Ben Coman wrote > But Class has an instance variable 'name', > and Class subclasses --> {ProtoObject class} He he, of course. Thanks for the clarification! Ben Coman wrote > should that instance variable and accessors be renamed to 'classname'? YES to a rename! Let's remove all mysterious gotchas for newbies (and me ha ha). This is an obscure and scary bug, because it prevents all operations on the package, so one can not even commit or file out the package. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Woe-unto-thee-who-assigns-to-class-side-name-tp485973… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 9, 2015

Re: [Pharo-dev] Code critic very bugged ?

by Thierry Goubier

2015-11-09 12:39 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > Hi, > > One thing I see there is a DNU #hasBindingOf: for spec toolsâ¦ I have a fix > for the that I will > commit today. > Thanks! this one is really annoying. Thierry > > Marcus > > On 08 Nov 2015, at 08:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > ah I forgot about that one, yes it does here it is > > http://pastebin.com/uW4AMphu > > On Sun, Nov 8, 2015 at 1:37 PM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > >> 2015-11-08 12:27 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >>> Hey guys I try to use shortcuts and arrow keys with nautilus and I get >>> this every time >>> >>> MNU : receiver of doSemanticsAnalysis: is nil >>> >>> in ASTCache at: aCompiledMethod >>> >>> I would paste the full stack but it keeps throwing me MNUs when I try to >>> do anything with the debugger. Seems like a pretty major bug , am I the >>> only one experiencing this ? >>> >> >> does the pharodebug.log contain the stack trace? >> >> >> >>> >>> I am on macos Yosemite using latest pharo 5 image and stable vm with >>> >>> wget -O- get.pharo.org/50+vm | bash >>> >>> >>> >

Nov. 9, 2015

Re: [Pharo-dev] Running without sources/changes ?

by Marcus Denker

> On 08 Nov 2015, at 13:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 04 Nov 2015, at 14:14, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 03 Nov 2015, at 17:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> Does anyone know if we can still run Pharo (4) without sources and without changes ? Years ago there used to be an option to 'abandon changes' and/or 'abandon sources', IIRC. Can we still do that ? I can't find this option in System Settings. I want to run just a reduced image on a server. >>> >> >> No, in Pharo4 it does not workâ¦ we should have a look again, if we have the time. >> >> What is clear is that we really need to find a better solution to .changes/.sourcesâ¦ >> >> Marcus > > It would be good to have this functionality back, but it is not a high priority. > > But in 4.0 even #cleanupForProduction did not work â¦ everything not tested does not work by definition. I am therefore skeptical every time we want to deploy differently than we use the system every dayâ¦ - The artefact on the CI server has to be the artefact of release - the artefact we use for development has to be the artefact of deployment. Marcus

Nov. 9, 2015

Re: [Pharo-dev] Code critic very bugged ?

by Marcus Denker

Hi, One thing I see there is a DNU #hasBindingOf: for spec toolsâ¦ I have a fix for the that I will commit today. Marcus > On 08 Nov 2015, at 08:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > ah I forgot about that one, yes it does here it is > > http://pastebin.com/uW4AMphu <http://pastebin.com/uW4AMphu> > > On Sun, Nov 8, 2015 at 1:37 PM Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > 2015-11-08 12:27 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>>: > Hey guys I try to use shortcuts and arrow keys with nautilus and I get this every time > > MNU : receiver of doSemanticsAnalysis: is nil > > in ASTCache at: aCompiledMethod > > I would paste the full stack but it keeps throwing me MNUs when I try to do anything with the debugger. Seems like a pretty major bug , am I the only one experiencing this ? > > does the pharodebug.log contain the stack trace? > > > > I am on macos Yosemite using latest pharo 5 image and stable vm with > > wget -O- get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash > >

Nov. 9, 2015

Re: [Pharo-dev] How to integrate change on class Point

by Marcus Denker

> On 08 Nov 2015, at 18:23, stepharo <stepharo(a)free.fr> wrote: > > There is a trick > Tx henrik > DangerousClassNotifier disable :) > Yes, but we should actually fix the class builder to not raise the error when just changing a commentâ¦ but then, this happens not often so I did not yet even report an issue for it. Marcus

Nov. 9, 2015

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

by Thierry Goubier

2015-11-09 10:21 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-11-09 8:07 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> mariano did you try the tool developed by mark rizun? >> > > I believe what he's looking for is past Mark tool capabilities for now. > Mark tool is something to invest on, certainly. > > But a small state of the art study on 'generalising refactorings' and > related wouldn't hurt. > > >> because I always fail to get the expression correct. >> We spent some times trying to document the pattern language but to us it >> is not really coherent. >> > > I just asked John and he described a lot ;) > > >> Jean-Christophe was expert in parse tree rewriting and he got lost. >> > > I think RB is the oldest and probably the most powerful refactoring > rewriting engine out there one can have a free access to (excluding general > program transformation frameworks, but I consider those to be different > beasts). > > Research afterwards decided that it should be considered a subset of model > transformations and I think the know-how on such engines was lost. It > doesn't help that it wasn't well published (the same goes with the DMS > toolkit). > As a point of interest, I'd be really happy to see how my example for Mariano would be written in more modern systems. Jean-Christophe, could you show us how that would be in Tom, the language referenced in [1] ? (i.e. if a selector contains 'oldSelector' in its name, to rewrite it with the substring 'oldSelector' replaced by 'newSelector', everywhere in the source code) Thierry [1] Ali Afroozeh, Jean-Christophe Bach, Mark Van den Brand, Adrian Johnstone, Maarten Manders, et al.. Island Grammar-based Parsing using GLL and Tom. *5th International Conference on Software Language Engineering - SLE 2012*, Sep 2012, Dresden, Germany. 2012 > > >> There is a chapter in PharoInProgress. > > >> We are prototyping alternatives because we need better tools. >> > > And for that, I'd say you're in for a lot of investment to beat Don > Roberts and John Brant (not forgetting they were not alone at that time). > > Note that an extension of Mark tool would make new users and power users > able to benefit immensely from the power of RB, and bring true progress on > the usability of refactoring engines. > > Side note: John Brant is taking about RB and SmaCC at Smalltalks: use that > occasion to ask questions! > > Thierry >

Nov. 9, 2015

Re: [Pharo-dev] Changing class template

by Thierry Goubier

2015-11-09 9:47 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > On 09 Nov 2015, at 06:50, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Le 09/11/2015 01:33, Yuriy Tymchuk a Ã©crit : > > > On 08 Nov 2015, at 20:14, Thierry Goubier > <thierry.goubier(a)gmail.com> wrote: > > Stef, > > I don't understand. I have never set a category in a class creation > template for the last three years. > > When I teach using Pharo, I allways tell students to create a > package, select the package in the browser and add a class there. > > Changing #category: for #package: (which is what the fix will be, I > bet) is useless. > > > Because what written there is not a package, itâs a package + tag. So > it would make sense to have > > â¦ package: âPacakgeNameâ tag: âTagNameâ > > > Trying to make it simpler for new students, I see :( > > > Exactly, because you say: âeach class has in a package and can have a tag, > and here you can define thatâ. Otherwise you have to explain that category > is actually a magical thing that splits into a package and a tag by > following some rules. > You'd better explain it that way given how it is implemented now. I don't think the package + tags choice improved anything there compared to package + sets of packages, especially regarding categories (we could have a one to one relation between category and package, which would be way simpler to explain). And now we need a higher abstraction than packages, the one represented for now by 'a group of packages loaded by a configuration or a baseline'. I'd say 'missed opportunity'. Now, I'd say no to any RPackage redesign, so we'll have to live with it and repatch the rest of the system (and the documentation). > > > But what Iâd really enjoy is to have a dedicated UI there. Because we > really use class templates as templates. 90% of a time I just change > the Superclass, Class and instance variables. > > > As I said. > > And 9% more I also add > a tag to the package. > > > What? You don't do a 'add a tag to a package' operation? You create tags > by side effect of a new class creation? > > > Of course. > Then, if you consider what you're asking for, I won't agree with it :) It clearly shows your IDE is defficient there. > > > (Your numbers don't add up to 100%. What is the one percent left for then? > ;)) > > > I guess Traits. > :) > > > So why we cannot have a UI with text fields for > this values? Later it can be fancier e.g. classVariables are hidden > by default and can be expanded on demand or if the are defined (I > donât like explaining class vars to people and I donât like them from > design point of view). Then also superclass field can have > autocompletion only from the defined classes prioritizing the ones > from the same package. Instance variables can be converted to slots > really fast by lookup, etcâ¦ > > > Look, you're making even more complex everytime. But you're welcome to > try; such a GUI can be added, yes, especially behind the add Class menu > item instead of reusing the full template. > > A wizard for class creation :) > > Note that on current Nautilus, if you use add Class in the menu, opening > the menu will auto-select what is behind the mouse click. And the template > is prefilled, which makes it a bit more complex to create a new clas on > Object. > > > Itâs not about creation, itâs about working with classes. > #compile:classified: is not present in the method template because no one > will never change it. Similarly Iâve never ever changed the `subclass:` > keyword, so why should it be editable? Iâve never changed > `instanceVariableNames:` keyword. Probably the only thing Iâve changed was > adding `uses:` when working with traits. But again, why do I have to recall > whether itâs called `uses:` or `using:` and type it between `subclass:` and > `instanceVariableNames:`? Wy I cannot just press a button âuse traitsâ and > a field will appear where I have to specify traits. > Now, why not? As I said, write a wizard behind the addClass. Like that, it's out of the way if we don't want to use it :) > > > > I mean, itâs nice that we can subclass by sending a message, but we > donât develop methods in a template like: > > compile: âmethodCodeâ classified: âprotocolNameâ > > > I do. When the browser is broken, it's sometime the only way left :) Or > editing Smalltalk code directly on github :) > > > Yes, but you are not doing that in Nautilus, and there is probably a > reason for that. Otherwise we can do an experiment: add > #compile:classified: to the method editor and see if people like it. > > > So maybe we make use of special UI for classes instead of plain > code. > > > Note that with smart suggestions, you can have both in the same apparently > plain code. > > > I didnât get that one :( > Well, take for example: SmaCCCodeGenerator subclass: #SmaCCSmalltalkCodeGenerator instanceVariableNames: 'isExpressions parseTreeCache category splitIndex' classVariableNames: 'MaxJumpSize' poolDictionaries: '' category: 'SmaCC-Development' If you right click on parseTreeCache, you can get as menu items: [image: Images intÃ©grÃ©es 1] Look: intelligent GUI, text template ;) > > But think of your usage, and also of the other usage: just beginner, new > student. > > > I donât know how the student thinks, but Iâd prefer to have 4 input fields: > > - superclass autocompleted with existing classes > - class name > - instance variables that will have visual separation for each var (eg: > http://xoxco.com/projects/code/tagsinput/example.html) > - package that will be already entered as it is now (and maybe have some > inactive style not to distract) > But you loose the message, as Peter pointed out. Mind you, those ideas in a class creation dialog, fine. Thierry > > Uko > > > And the last one will show you that our toolset is geared towards the > power user. And this is not going to change anytime soon, to the contrary. > > Thierry > > >

Nov. 9, 2015

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

by Thierry Goubier

2015-11-09 8:07 GMT+01:00 stepharo <stepharo(a)free.fr>: > mariano did you try the tool developed by mark rizun? > I believe what he's looking for is past Mark tool capabilities for now. Mark tool is something to invest on, certainly. But a small state of the art study on 'generalising refactorings' and related wouldn't hurt. > because I always fail to get the expression correct. > We spent some times trying to document the pattern language but to us it > is not really coherent. > I just asked John and he described a lot ;) > Jean-Christophe was expert in parse tree rewriting and he got lost. > I think RB is the oldest and probably the most powerful refactoring rewriting engine out there one can have a free access to (excluding general program transformation frameworks, but I consider those to be different beasts). Research afterwards decided that it should be considered a subset of model transformations and I think the know-how on such engines was lost. It doesn't help that it wasn't well published (the same goes with the DMS toolkit). > There is a chapter in PharoInProgress. > We are prototyping alternatives because we need better tools. > And for that, I'd say you're in for a lot of investment to beat Don Roberts and John Brant (not forgetting they were not alone at that time). Note that an extension of Mark tool would make new users and power users able to benefit immensely from the power of RB, and bring true progress on the usability of refactoring engines. Side note: John Brant is taking about RB and SmaCC at Smalltalks: use that occasion to ask questions! Thierry

Nov. 9, 2015

Re: [Pharo-dev] Changing class template

by Yuriy Tymchuk

Ok, maybe for students itâs bad, but for myself Iâd like something like that :) Uko > On 09 Nov 2015, at 10:06, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > Power users use the template directly (saves you one, two, three mouse clicks and a few mouse mouvements) > > +1 > > From student/beginner perspective I would argue that it is very valuable for them to see that creating class is just a regular message send and not some special syntax/magic. Adding UI would alienate them from this knowledge/revelation. > > On Mon, Nov 9, 2015 at 9:47 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > >> On 09 Nov 2015, at 06:50, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 09/11/2015 01:33, Yuriy Tymchuk a Ã©crit : >>> >>>> On 08 Nov 2015, at 20:14, Thierry Goubier >>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>>> >>>> Stef, >>>> >>>> I don't understand. I have never set a category in a class creation >>>> template for the last three years. >>>> >>>> When I teach using Pharo, I allways tell students to create a >>>> package, select the package in the browser and add a class there. >>>> >>>> Changing #category: for #package: (which is what the fix will be, I >>>> bet) is useless. >>> >>> Because what written there is not a package, itâs a package + tag. So >>> it would make sense to have >>> >>> â¦ package: âPacakgeNameâ tag: âTagNameâ >> >> Trying to make it simpler for new students, I see :( > > Exactly, because you say: âeach class has in a package and can have a tag, and here you can define thatâ. Otherwise you have to explain that category is actually a magical thing that splits into a package and a tag by following some rules. > >> >>> >>> But what Iâd really enjoy is to have a dedicated UI there. Because we >>> really use class templates as templates. 90% of a time I just change >>> the Superclass, Class and instance variables. >> >> As I said. >> >>> And 9% more I also add >>> a tag to the package. >> >> What? You don't do a 'add a tag to a package' operation? You create tags by side effect of a new class creation? > > Of course. > >> >> (Your numbers don't add up to 100%. What is the one percent left for then? ;)) > > I guess Traits. > >> >>> So why we cannot have a UI with text fields for >>> this values? Later it can be fancier e.g. classVariables are hidden >>> by default and can be expanded on demand or if the are defined (I >>> donât like explaining class vars to people and I donât like them from >>> design point of view). Then also superclass field can have >>> autocompletion only from the defined classes prioritizing the ones >>> from the same package. Instance variables can be converted to slots >>> really fast by lookup, etcâ¦ >> >> Look, you're making even more complex everytime. But you're welcome to try; such a GUI can be added, yes, especially behind the add Class menu item instead of reusing the full template. >> >> A wizard for class creation :) >> >> Note that on current Nautilus, if you use add Class in the menu, opening the menu will auto-select what is behind the mouse click. And the template is prefilled, which makes it a bit more complex to create a new clas on Object. > > Itâs not about creation, itâs about working with classes. #compile:classified: is not present in the method template because no one will never change it. Similarly Iâve never ever changed the `subclass:` keyword, so why should it be editable? Iâve never changed `instanceVariableNames:` keyword. Probably the only thing Iâve changed was adding `uses:` when working with traits. But again, why do I have to recall whether itâs called `uses:` or `using:` and type it between `subclass:` and `instanceVariableNames:`? Wy I cannot just press a button âuse traitsâ and a field will appear where I have to specify traits. > > >> >>> I mean, itâs nice that we can subclass by sending a message, but we >>> donât develop methods in a template like: >>> >>> compile: âmethodCodeâ classified: âprotocolNameâ >> >> I do. When the browser is broken, it's sometime the only way left :) Or editing Smalltalk code directly on github :) > > Yes, but you are not doing that in Nautilus, and there is probably a reason for that. Otherwise we can do an experiment: add #compile:classified: to the method editor and see if people like it. > >> >>> So maybe we make use of special UI for classes instead of plain >>> code. >> >> Note that with smart suggestions, you can have both in the same apparently plain code. > > I didnât get that one :( > >> >> But think of your usage, and also of the other usage: just beginner, new student. > > I donât know how the student thinks, but Iâd prefer to have 4 input fields: > > - superclass autocompleted with existing classes > - class name > - instance variables that will have visual separation for each var (eg: http://xoxco.com/projects/code/tagsinput/example.html <http://xoxco.com/projects/code/tagsinput/example.html>) > - package that will be already entered as it is now (and maybe have some inactive style not to distract) > > Uko > >> >> And the last one will show you that our toolset is geared towards the power user. And this is not going to change anytime soon, to the contrary. >> >> Thierry > >

Nov. 9, 2015