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

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

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

by Thierry Goubier

2015-11-09 6:38 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Mariano, > > Le 09/11/2015 01:13, Mariano Martinez Peck a Ã©crit : > >> >> >> On Fri, Nov 6, 2015 at 1:59 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> ... > >> >> Hi Thierry, >> >> I am trying to achieve a similar case like the one I commented in this >> post but I am unable to find the way. >> Previously I wanted to replace say the literal #oldSelector to >> #newSelector. Now, I need to use regular expressions. I mean, I would >> need to find matches of '*oldSelector*' and do the replace with >> 'newSelector'. For example, the search may find >> '*pre*oldSelector*post*' and I want it to be replaced by >> '*pre*newSelector*post'. *And of course, I don't know in advance what >> pre and post strings there could be. >> > > What you need to do there is to use a match block after the @selector > > `{:node | node selector matches: '.*oldSelector.*'} > > Which would mean that your patterns become: > > rewriter > replace: '``@object `oldSelector {:node | node selector matches: > '.*oldSelector.*'}' > with: '``@object `newSelector {:node | node selector }'. > > Wait, not entirely sure. I think you need to add a dictionary in the block > to give the with: argument the pre and post string. And I'm not sure about > the regular expression above as well. > > I need to have access to the SmaCC code source, so I'll answer to you a > bit later. Ok, here is a first try that make a change pre and post included: | tree | RBParseTreeRewriter new replace: '`@object `oldSelector `{:node | node selector asString matchesRegex: ''.*oldSelector.*''}' with: '`@object newSelector'; executeTree: (tree := RBParser parseMethod: 'DoIt ^ [:proxy | proxy at: #oldSelector. proxy preoldSelector. proxy oldSelectorAnotherMethod. proxy do: ''oldSelectorAndSomething''. "a comment with #oldSelector " ]'). tree newSource But it does not replace yet the right selector. For that, I will recreate a message send: | tree | RBParseTreeRewriter new replace: '`object `oldSelector `{:node | node selector asString matchesRegex: ''.*oldSelector.*''} `@args' with: '`{RBMessageNode receiver: `object selector: (`oldSelector selector copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol arguments: `@args}'; executeTree: (tree := RBParser parseMethod: 'DoIt ^ [:proxy | proxy at: #oldSelector. proxy preoldSelector. proxy oldSelectorAnotherMethod. proxy do: ''oldSelectorAndSomething''. "a comment with #oldSelector " ]'). tree newSource Now, I haven't tested with arguments on the message. Look how you can use pattern variables inside the blocks :) This is very cool and extremely powerfull. Thierry > > > >> Also..do you know where can I find some more info about RB? For example, >> if I read this: >> >> rewriter >> replace: '``@object ' , oldSeletor >> with: '``@object ' , newSelector. >> >> Where can I read that ``@object means XXX .. ? >> > > There is a first level of explanation in the Pharo for the Enterprise > book; but, yes the pattern language is fairly complex. > > Are you going to Smalltalks? John Brant is there and will give a talk on > RB and SmaCC (two talks, I believe). > > Thierry > > > Thanks in advance! >> >> >> >> Or a cascade: a RBParseTreeSearcher which matches blocks; on >> each block node you activate a rewriter. >> >> However, there is an issue in rewriting blocks contents, because >> it supposes that the method defining the block is recompiled; >> it's significantly harder to make changes to the code of live >> blocks (change the bytescode itself? What if the block has >> multiples instances?). >> >> Thierry >> >> >> If not, I think my easiest path is to automatically compile >> dummy/temporal classes/methods from the rules, perform the >> refactor, then move source from methods to block closures, >> and finally remove created classes. >> >> Any pointer is appreciated. >> >> best, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Nov. 9, 2015

Re: [Pharo-dev] Changing class template

by Peter UhnÃ¡k

> 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> wrote: > > 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. > > > > 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) > - 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

Re: [Pharo-dev] Changing class template

by Yuriy Tymchuk

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

Re: [Pharo-dev] Ubuntu fullscreen problems

by Nicolai Hess

2015-11-09 8:10 GMT+01:00 stepharo <stepharo(a)free.fr>: > > > Le 28/10/15 20:14, J.F. Rick a Ã©crit : > > Cool. I guess if there is a bug report on squeak then there is no reason > to create one on pharo. > > > Seriously? > Do you think that we have the time to look at Squeak bug tracker? > If it is not in fogbugz it does not exist. Try to simplify our live > instead of making it more complex. > > Stef > not a problem. I opened the bug on squeak and I keep track on it. > > If you need someone to test a solution on Ubuntu 15.10, let me know. > > On Wed, Oct 28, 2015 at 11:21 AM Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> 2015-10-28 15:35 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >>> I think there must be some incompatibility between Pharo and the host >>> window manager/desktop environment. >>> >>> On Debian/dwm (I am using Ubuntu VM) I can reproduce (1), but not (2). >>> >>> There is however interesting behavior... if I try to switch desktop >>> while in fullscreen it doesn't switch, however once I switch back to >>> non-fullscreen, suddenly I jump to the other desktop, as if the keyboard >>> shortcut for the switch got buffered somewhere... >>> >>> Opening a issue in FogzBugz is a good idea so it doesn't get forgotten. >>> >>> Peter >>> >>> On Wed, Oct 28, 2015 at 3:15 PM, J.F. Rick < <self(a)je77.com> >>> self(a)je77.com> wrote: >>> >>>> Hi everybody, >>>> >>>> I just upgraded to Ubuntu 15.10 and am using Unity User Interface. I >>>> want Pharo to use the full screen (i.e., above the menu bar and launcher). >>>> Inside Pharo, I can choose "Toggle full screen mode". This works to some >>>> extent but has some problems: >>>> >>>> (1) I can no longer switch applications or desktops (i.e., pager). So >>>> it stops me doing work where I move between Pharo and a browser. This may >>>> be expected functionality. >>>> >>>> (2) More problematically, when I try to switch out of full screen mode >>>> by choosing "Toggle full screen mode", the Pharo interface completely >>>> disappears (just a giant gray area) and no mouse or keyboard events seem to >>>> register. I have to use command line to kill it. In good news, I can use >>>> "save and quit" instead and relaunching it just has it in maximum mode >>>> (full screen but launcher and menu bar are visible). I can then toggle full >>>> screen mode twice to get back to full screen. >>>> >>>> I searched for this on FogBugz but found nothing. Is there a >>>> workaround? This seems like a VM issue. Is there a newer VM that fixes >>>> this? I just used the most recent one on the Pharo 4.0 download page. >>>> >>>> If nobody has a fix, I'll open a case on FogBugz. This isn't a large >>>> problem but it would be nice to have this >>>> >>> >> It is a know problem (with possible fixes) >> (http://bugs.squeak.org/view.php?id=7812) >> You can not switch back from fullscreen on a linux 64-bit system ( >> http://bugs.squeak.org/view.php?id=7833) (maybe not only 32bit issue, >> but just the more recent windowmanager) >> >> >> >>> >>>> Cheers, >>>> >>>> Jeff >>>> >>> >>> >> >

Nov. 9, 2015

Re: [Pharo-dev] Ubuntu fullscreen problems

by stepharo

Le 28/10/15 20:14, J.F. Rick a Ã©crit : > Cool. I guess if there is a bug report on squeak then there is no > reason to create one on pharo. Seriously? Do you think that we have the time to look at Squeak bug tracker? If it is not in fogbugz it does not exist. Try to simplify our live instead of making it more complex. Stef > If you need someone to test a solution on Ubuntu 15.10, let me know. > > On Wed, Oct 28, 2015 at 11:21 AM Nicolai Hess <nicolaihess(a)gmail.com > <mailto:nicolaihess@gmail.com>> wrote: > > 2015-10-28 15:35 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>>: > > I think there must be some incompatibility between Pharo and > the host window manager/desktop environment. > > On Debian/dwm (I am using Ubuntu VM) I can reproduce (1), but > not (2). > > There is however interesting behavior... if I try to switch > desktop while in fullscreen it doesn't switch, however once I > switch back to non-fullscreen, suddenly I jump to the other > desktop, as if the keyboard shortcut for the switch got > buffered somewhere... > > Opening a issue in FogzBugz is a good idea so it doesn't get > forgotten. > > Peter > > On Wed, Oct 28, 2015 at 3:15 PM, J.F. Rick <self(a)je77.com > <mailto:self@je77.com>> wrote: > > Hi everybody, > > I just upgraded to Ubuntu 15.10 and am using Unity User > Interface. I want Pharo to use the full screen (i.e., > above the menu bar and launcher). Inside Pharo, I can > choose "Toggle full screen mode". This works to some > extent but has some problems: > > (1) I can no longer switch applications or desktops (i.e., > pager). So it stops me doing work where I move between > Pharo and a browser. This may be expected functionality. > > (2) More problematically, when I try to switch out of full > screen mode by choosing "Toggle full screen mode", the > Pharo interface completely disappears (just a giant gray > area) and no mouse or keyboard events seem to register. I > have to use command line to kill it. In good news, I can > use "save and quit" instead and relaunching it just has it > in maximum mode (full screen but launcher and menu bar are > visible). I can then toggle full screen mode twice to get > back to full screen. > > I searched for this on FogBugz but found nothing. Is there > a workaround? This seems like a VM issue. Is there a newer > VM that fixes this? I just used the most recent one on the > Pharo 4.0 download page. > > If nobody has a fix, I'll open a case on FogBugz. This > isn't a large problem but it would be nice to have this > > > It is a know problem (with possible fixes) > (http://bugs.squeak.org/view.php?id=7812) > You can not switch back from fullscreen on a linux 64-bit system > (http://bugs.squeak.org/view.php?id=7833) (maybe not only 32bit > issue, but just the more recent windowmanager) > > > Cheers, > > Jeff > > >

Nov. 9, 2015

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

by stepharo

mariano did you try the tool developed by mark rizun? 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. Jean-Christophe was expert in parse tree rewriting and he got lost. There is a chapter in PharoInProgress. We are prototyping alternatives because we need better tools. Stef Le 9/11/15 06:38, Thierry Goubier a Ã©crit : > Hi Mariano, > > Le 09/11/2015 01:13, Mariano Martinez Peck a Ã©crit : >> >> >> On Fri, Nov 6, 2015 at 1:59 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> > ... >> >> Hi Thierry, >> >> I am trying to achieve a similar case like the one I commented in this >> post but I am unable to find the way. >> Previously I wanted to replace say the literal #oldSelector to >> #newSelector. Now, I need to use regular expressions. I mean, I would >> need to find matches of '*oldSelector*' and do the replace with >> 'newSelector'. For example, the search may find >> '*pre*oldSelector*post*' and I want it to be replaced by >> '*pre*newSelector*post'. *And of course, I don't know in advance what >> pre and post strings there could be. > > What you need to do there is to use a match block after the @selector > > `{:node | node selector matches: '.*oldSelector.*'} > > Which would mean that your patterns become: > > rewriter > replace: '``@object `oldSelector {:node | node selector matches: > '.*oldSelector.*'}' > with: '``@object `newSelector {:node | node selector }'. > > Wait, not entirely sure. I think you need to add a dictionary in the > block to give the with: argument the pre and post string. And I'm not > sure about the regular expression above as well. > > I need to have access to the SmaCC code source, so I'll answer to you > a bit later. > >> >> Also..do you know where can I find some more info about RB? For example, >> if I read this: >> >> rewriter >> replace: '``@object ' , oldSeletor >> with: '``@object ' , newSelector. >> >> Where can I read that ``@object means XXX .. ? > > There is a first level of explanation in the Pharo for the Enterprise > book; but, yes the pattern language is fairly complex. > > Are you going to Smalltalks? John Brant is there and will give a talk > on RB and SmaCC (two talks, I believe). > > Thierry > >> Thanks in advance! >> >> >> >> Or a cascade: a RBParseTreeSearcher which matches blocks; on >> each block node you activate a rewriter. >> >> However, there is an issue in rewriting blocks contents, because >> it supposes that the method defining the block is recompiled; >> it's significantly harder to make changes to the code of live >> blocks (change the bytescode itself? What if the block has >> multiples instances?). >> >> Thierry >> >> >> If not, I think my easiest path is to automatically compile >> dummy/temporal classes/methods from the rules, perform the >> refactor, then move source from methods to block closures, >> and finally remove created classes. >> >> Any pointer is appreciated. >> >> best, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > >

Nov. 9, 2015

Re: [Pharo-dev] Changing class template

by Thierry Goubier

Le 08/11/2015 20:29, Ferlicot D. Cyril a Ã©crit : > Le 08/11/2015 20:14, Thierry Goubier a Ã©crit : >> 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. >> >> Thierry >> >> > > I understand because when I explain a little Pharo to friends who only > learned Java, I like to explain the advantage to have everything as an > object and every action as a message. And one of the first message we > encounter is the class template. We can explain Â«We send this message to > "Object" and with this message we have arguments which areâ¦Â». But when > it comes to the package we have to say Â«And for the category you pass > the package name and don't care about the "category" nameÂ» because this > is too much to explain the tags thing to beginners. Which would mean the tags have added complexity in that regard. > I think that what is easily visible should be very explicit, and more > advances feature should be in menu or things like that to help beginners. I'm not sure. Power users use the template directly (saves you one, two, three mouse clicks and a few mouse mouvements) and I'd suggest using the menu for beginners (you can direct them to the menu and they will remember they are doing that 'action' of adding a class: a dialog probably also helps them to focus on it and the questions they have to answer when they are creating a class). Thierry

Nov. 9, 2015