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

Re: [Pharo-dev] Rules

by Yuriy Tymchuk

> On 24 Nov 2015, at 17:29, Ben Coman <btc(a)openinworld.com> wrote: > > On Tue, Nov 24, 2015 at 11:45 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> On 24 Nov 2015, at 14:10, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Tue, Nov 24, 2015 at 4:32 PM, Nicolas Anquetil >> <nicolas.anquetil(a)inria.fr> wrote: >> On 23/11/2015 22:14, stepharo wrote: >> Le 22/11/15 22:11, Yuriy Tymchuk a Ã©crit : >> >> >> Hi. >> >> The rule is correct. Sending a different message to super may be >> confusing. In this case you are in âprintOn:â method and you are sending >> âprintOn:nextPutAll:â to super. The idea is that you have to send >> âprintOn:nextPutAll:â to self and then either it will invoke the super one, >> you there will be an overridden method in your current class. >> >> exactly but do you expect a newbie to understand anything with the current >> explanation? >> I do not. >> >> Rewrite super messages to self messages when both refer to same method" >> >> >> What about : >> >> >> Sorry :) both of these make my head hurt. I think Stef's was clearer. >> The useful part there is that it reports the actual identifier causing >> the problem, which makes it more obvious this is not what was meant, >> from which even a newbie may infer the missing period. >> >> "'super' should call the same selector. Send different selector to 'self' >> then use 'super' in this one." >> ? >> >> >> btw, is this just commonly how super is used, or is it really bad to >> call a different super method? >> I'm sure I've done that on occasion. >> >> >> It makes harder to extend your code. Because if method `a` calls method `b`, >> then even if method `b` is not defined in your class, I can subclass and >> redefine method b. Otherwise I have to subclass and redefine `a` although >> `a` is fine, but I want to run my `b` and not the one of superclass. >> >> >> Uko >> >> > > Thanks Uko. I was considering a case where my new subclass has > redefined 'b', but I want my 'a' to avoid my 'b' and use the > superclass one. > > (Sorry I can't remember the use case) > cheers -ben Hi, no rule is perfect, and there are definitely cases that work the other way around. But we try to focus on the best practices. Also I think this influences the maintainability of code. Because in the suggested by the rule, you have method `a` with one responsibility and it uses method `b` with another responsibility. Now when you call method `b` from the super class, all logic becomes more complicated. Uko > > >> cheers -ben >> >> >> or: >> >> "should not send a different message to super (send different message to >> self and then call super from it)" >> ? >> >> >> >> nicolas >> >> >> Sucks >> >> >> Secondly, there is an issue with âsends unkown selectorâ. Iâve also >> noticed it recently. I think that it happens because the rule has a special >> cace, and I messed up something with refresh. This is the next thing on my >> TODO list. >> >> Cheers. >> Uko >> >> >> On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> On 22 Nov 2015, at 12:20, stepharo <stepharo(a)free.fr> wrote: >> >> With the following (broken) definition >> >> >> : aStream >> super printOn: aStream >> aStream nextPutAll: '(', faces printString , ')' >> >> I got this strange rule: >> >> Rewrite super messages to self messages when both refer to same >> method >> >> I do not get it and it looks really suspicious to me. >> Any suggestions? >> >> >> The rule is meant to catch the case when when âsuperâ can be âselfâ as >> there is no #printOn: >> defined in the class. >> >> But here it looks like it is wrong: it would be an infinite loop. >> >> I think it could be related to this other bug: I have seen that the >> rules are not correctly updated >> when you add methods. (I wanted to add an issue for that but did not >> yet). E.g. I often get >> a âsends unkown selectorâ for self sends and then I check â> method is >> there, I just added it! >> >> So here this means that you added a new printOn:, the rules do not >> update, and it thinks >> that there is no printOn:. >> >> So the real bug is that added methods need to be taken into account by >> QA. >> >> Marcus >> >> >> >> >> >> >> >> -- >> Nicolas Anquetil >> RMod team -- Inria Lille

Nov. 24, 2015

Re: [Pharo-dev] Improving API of Date, Month....

by stepharo

Hi guys I made the mistake to think that it was a good move to improve and make the core more full (and complex in the past). Now what I would love is the following. - keep and reduce if necessary the core date classes (only used internally by the system) - have nice packages that we can load to represent time / calendar -- chronos -- aconcagua -- or a new one That do it the right way: with locale and so on. Why? because it can be complex and verbose and we want to have a small core (for many different reasons). About the durationFormatter I think that we should definitively have more strategies to represent dates and other within a nice date/calendar package. I would love that someone propose something to get the nice extensible Calendar/Date package Stef Le 24/11/15 16:25, Esteban A. Maringolo a Ã©crit : > 2015-11-24 12:14 GMT-03:00 Skip Lentz <skip.lentz(a)inria.fr>: >> Hi, >> >> I also had an idea for a method which returns the most significant unit of a Duration. >> >> For example, you have a duration of 432 days, 3 hours, 21 minutes, 5 seconds, etc., and >> it would return you "432 days" (or just â1 yearâ). I encountered this when wanting to create >> a time indication on e.g. a commit or a comment. Itâs much more readable and user-friendly >> than a timestamp. >> >> Would this be a nice addition to the Duration API? > It would be nice to have. But why not something like a > DurationFormatter? that in turn collaborates with the Locale to ge the > words for "Year, Month, Week" in the current language. > > Regards! > >

Nov. 24, 2015

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

by Mariano Martinez Peck

On Tue, Nov 24, 2015 at 3:04 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Mariano, > > Le 22/11/2015 23:31, Mariano Martinez Peck a Ã©crit : > >> >> >> ... > >> >> You know what is funny? I run all AST-Tests-Core from Pharo and NONE >> halt on #createBlockFor: ... >> I even run all those from Refactoring-Tests-Core. >> *So..it seems there is not tests that covers the usage of >> #createBlockFor: :(* >> > > Ok. I'll have a scan of all the RB tests and add additional tests then. > There is an issue John pointed to Nicolai and me that needs solving as well. > > OK. Great. Once you do it let me know and I will see if I can port and make them work for GemStone. > BTW, do you image other cases like this? >> >> >> You mean storing those RB rules? I try to collect them if I see some >> (or participate to), or remember where I see them. >> >> >> No, I mean the compilation of block closures that would try to bind >> "self". Anyway, I will search if I find more. >> > > Thanks. > > I used to know where the RBRewriteTree chapter was in the Pharo >> books, but it seems to have disappeared, so I have recreated a copy >> that I'll try to update. >> >> >> >> Thanks, please share it with me when you made it because I could not >> find it weeks ago. >> > > My fork of the Pharo for the enterprise book has it: > > https://github.com/ThierryGoubier/PharoForTheEnterprise-english > > But I don't have a CI building it yet. > > Thanks! I will read it today! -- Mariano http://marianopeck.wordpress.com

Nov. 24, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 24, 2015

[pharo-project/pharo-core] 76a4cf: 50466

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 76a4cf91a7cb12f0f193be5565c75f648492f51e https://github.com/pharo-project/pharo-core/commit/76a4cf91a7cb12f0f193be55… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-24 (Tue, 24 Nov 2015) Changed paths: M Kernel.package/DelayExperimentalCourageousScheduler.class/README.md M Kernel.package/DelayExperimentalCourageousScheduler.class/instance/low priority processes/schedule_.st M Kernel.package/DelayExperimentalSemaphoreScheduler.class/instance/low priority processes/schedule_.st M Kernel.package/DelayExperimentalSpinScheduler.class/README.md M Kernel.package/DelayExperimentalSpinScheduler.class/instance/low priority processes/schedule_.st M Kernel.package/DelayExperimentalSpinScheduler.class/instance/low priority processes/unschedule_.st M NECompletion.package/NECContext.class/instance/accessing/createModel.st A NECompletion.package/NECContext.class/instance/private-type-guessing/completionTokenIsLiteral.st A NECompletion.package/NECEmptyModel.class/README.md A NECompletion.package/NECEmptyModel.class/definition.st A NECompletion.package/NECEmptyModel.class/instance/accessing/initializeSelectors.st A NECompletion.package/NECEmptyModel.class/instance/action/narrowWith_.st A NECompletion.package/NECEmptyModel.class/instance/testing/isEmpty.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50465.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50466.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50465.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50466.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50466 17045 Auto-completion should not be used when typing numbers https://pharo.fogbugz.com/f/cases/17045 13756 Delay scheduling deadlock https://pharo.fogbugz.com/f/cases/13756 http://files.pharo.org/image/50/50466.zip

Nov. 24, 2015

Re: [Pharo-dev] Improving API of Date, Month....

by Hilaire

Yes, I badly need to get it localised I added class accessors to ChronologyConstants to modify month and day names. Hilaire Le 24/11/2015 15:59, stepharo a Ã©crit : > Hi > > I was reading the code of Date and I was expecting to get some methods > such as > monthNames > dayNames > daysInMonths > > Ok they are stored in ChronologyConstants but they are not accessible. > There is no monthNames nor > > Do I imply something strange or silly? > I think that it would make sense to add them. > > Stef > > -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Nov. 24, 2015

Re: [Pharo-dev] Seaside REST on Pharo 50

by Marcus Denker

> On 24 Nov 2015, at 12:43, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote: > > Hi, > > We are currently using seaside, magritte, reef etc to do a project at school. We also have to do a mobile app (written in Java :(), so we are doing a REST service to access the database from the mobile app. > > We are working on Pharo 50, and we noticed that Seaside-REST is not working anymore. > For simple get, it is ok, for example : > > test > <get> > ^ 'foo' > > but if you want to have a complete path like that : > > test: aValue > <get> > <path: '/foo?value={aValue}'> > ^ 'foo' > > You get a DNU RBVariableNode>>key during the route creating (Same on pharo 40 is working). > > Any idea why ? > Can you provide an image where this happens? (just knowing what to load would take some effort elseâ¦) Marcus

Nov. 24, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Thierry Goubier

Hi Skip, 2015-11-24 17:30 GMT+01:00 Skip Lentz <skip.lentz(a)inria.fr>: > Hi again, > > I wil try to respond to most of you in this e-mail: > > @ Thierry: > > > Would you be able to retrieve the same information from github that > GitFileTree does when it extract package version history information? > > It would be nice to have some less metadata in the repository (or none at > all), especially for merging. Method and author timestamps can be gathered > from the commit information, the âversionâ fill in the monticello.meta > directory is not necessary too I think, since we have the commit messages > obviously.. > Well, GitFileTree has all that code: - Monticello metadata extraction from git logs - Filetree without Metadata Some of the information in the meta directory is necessary (pre/post load scripts). > > I think having a FileTree reader/writer that is not coupled to Monticello > would be good, but maybe Iâm saying something that is not possible. > No, it is possible (everything is), but a bit complex for maintenance (how do you track changes and corrections in the FileTree code?). > > > - I get NeoJSON parser errors. > > Yes me too now when switching repositories. It appears when you switch > from a repository, it uses the same branch name of the old one. > Ok. > > > - I don't get all my repositories (well, in practice allmost none, > however I get all the pharo books), so I can't test that metadata-less. > > Alright so this is odd.. Martin had the same behavior. Thank you for all > your feedback, itâs very helpful. > Maybe just an effect of the ordering (github gives you a list of repositories, isn't it?) > > > Nice to see that nice graph widget put to good use :) But it could have > less white space on the left. > > True, I didnât fine tune the small details yet. ;) > > > I'm also a taker for a few more comments... > > Yes youâre right, some classes lack comments. Gah, so many TODOs. > Welcome to the world of interesting software :) > > @ Dale & Thierry: > > > Now, how do I contribute if I want to? Where is the repository I should > fork on github? I'm also a taker for a few more comments.. > > > Very interesting ... if you put your project up on github, I would fork > it and port it to tODE as this is something that has been on my todo list > for awhile:) > > > I will set up a GitHub repository tomorrow. Right now itâs on > SmalltalkHub, but I think itâs a good idea to put it on GitHub (if only for > doing versioning with the tool itself). Then youâll be able to fork etc. > > Iâll report back in this thread. > > @ Dimitris: > > > By the way do you develop this using the latest pharo 5 image and latest > pharo vm ? > > Yes I do. > > The bugs appear differ a lot from user to user. > Some have trouble logging in, some donât. Some people donât get all the > repositories in the list, some do, etc. > > @ Stef: > > > - help if you want > > Help is always welcome! Great to see that so many people take interest. > > So summary TODO list: > > - Put the repository on GitHub for everyone to collaborate > - More documentation > - Fix some of those pesky bugs which vary from person to person. > Thierry

Nov. 24, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Skip Lentz

Hi again, I wil try to respond to most of you in this e-mail: @ Thierry: > Would you be able to retrieve the same information from github that GitFileTree does when it extract package version history information? It would be nice to have some less metadata in the repository (or none at all), especially for merging. Method and author timestamps can be gathered from the commit information, the âversionâ fill in the monticello.meta directory is not necessary too I think, since we have the commit messages obviously.. I think having a FileTree reader/writer that is not coupled to Monticello would be good, but maybe Iâm saying something that is not possible. > - I get NeoJSON parser errors. Yes me too now when switching repositories. It appears when you switch from a repository, it uses the same branch name of the old one. > - I don't get all my repositories (well, in practice allmost none, however I get all the pharo books), so I can't test that metadata-less. Alright so this is odd.. Martin had the same behavior. Thank you for all your feedback, itâs very helpful. > Nice to see that nice graph widget put to good use :) But it could have less white space on the left. True, I didnât fine tune the small details yet. ;) > I'm also a taker for a few more comments... Yes youâre right, some classes lack comments. Gah, so many TODOs. @ Dale & Thierry: > Now, how do I contribute if I want to? Where is the repository I should fork on github? I'm also a taker for a few more comments.. > Very interesting ... if you put your project up on github, I would fork it and port it to tODE as this is something that has been on my todo list for awhile:) I will set up a GitHub repository tomorrow. Right now itâs on SmalltalkHub, but I think itâs a good idea to put it on GitHub (if only for doing versioning with the tool itself). Then youâll be able to fork etc. Iâll report back in this thread. @ Dimitris: > By the way do you develop this using the latest pharo 5 image and latest pharo vm ? Yes I do. The bugs appear differ a lot from user to user. Some have trouble logging in, some donât. Some people donât get all the repositories in the list, some do, etc. @ Stef: > - help if you want Help is always welcome! Great to see that so many people take interest. So summary TODO list: - Put the repository on GitHub for everyone to collaborate - More documentation - Fix some of those pesky bugs which vary from person to person.

Nov. 24, 2015

Re: [Pharo-dev] Rules

by Ben Coman

On Tue, Nov 24, 2015 at 11:45 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 24 Nov 2015, at 14:10, Ben Coman <btc(a)openinworld.com> wrote: > > On Tue, Nov 24, 2015 at 4:32 PM, Nicolas Anquetil > <nicolas.anquetil(a)inria.fr> wrote: > On 23/11/2015 22:14, stepharo wrote: > Le 22/11/15 22:11, Yuriy Tymchuk a Ã©crit : > > > Hi. > > The rule is correct. Sending a different message to super may be > confusing. In this case you are in âprintOn:â method and you are sending > âprintOn:nextPutAll:â to super. The idea is that you have to send > âprintOn:nextPutAll:â to self and then either it will invoke the super one, > you there will be an overridden method in your current class. > > exactly but do you expect a newbie to understand anything with the current > explanation? > I do not. > > Rewrite super messages to self messages when both refer to same method" > > > What about : > > > Sorry :) both of these make my head hurt. I think Stef's was clearer. > The useful part there is that it reports the actual identifier causing > the problem, which makes it more obvious this is not what was meant, > from which even a newbie may infer the missing period. > > "'super' should call the same selector. Send different selector to 'self' > then use 'super' in this one." > ? > > > btw, is this just commonly how super is used, or is it really bad to > call a different super method? > I'm sure I've done that on occasion. > > > It makes harder to extend your code. Because if method `a` calls method `b`, > then even if method `b` is not defined in your class, I can subclass and > redefine method b. Otherwise I have to subclass and redefine `a` although > `a` is fine, but I want to run my `b` and not the one of superclass. > > > Uko > > Thanks Uko. I was considering a case where my new subclass has redefined 'b', but I want my 'a' to avoid my 'b' and use the superclass one. (Sorry I can't remember the use case) cheers -ben > cheers -ben > > > or: > > "should not send a different message to super (send different message to > self and then call super from it)" > ? > > > > nicolas > > > Sucks > > > Secondly, there is an issue with âsends unkown selectorâ. Iâve also > noticed it recently. I think that it happens because the rule has a special > cace, and I messed up something with refresh. This is the next thing on my > TODO list. > > Cheers. > Uko > > > On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 22 Nov 2015, at 12:20, stepharo <stepharo(a)free.fr> wrote: > > With the following (broken) definition > > > : aStream > super printOn: aStream > aStream nextPutAll: '(', faces printString , ')' > > I got this strange rule: > > Rewrite super messages to self messages when both refer to same > method > > I do not get it and it looks really suspicious to me. > Any suggestions? > > > The rule is meant to catch the case when when âsuperâ can be âselfâ as > there is no #printOn: > defined in the class. > > But here it looks like it is wrong: it would be an infinite loop. > > I think it could be related to this other bug: I have seen that the > rules are not correctly updated > when you add methods. (I wanted to add an issue for that but did not > yet). E.g. I often get > a âsends unkown selectorâ for self sends and then I check â> method is > there, I just added it! > > So here this means that you added a new printOn:, the rules do not > update, and it thinks > that there is no printOn:. > > So the real bug is that added methods need to be taken into account by > QA. > > Marcus > > > > > > > > -- > Nicolas Anquetil > RMod team -- Inria Lille > >

Nov. 24, 2015