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

Re: [Pharo-dev] red banner and links with safari?

by Stephan Eggermont

On 22-11-15 23:53, Ben Coman wrote: > I guess the only real fix for the https pages produced to reference > https stylesheets. > cheers -ben > > On Mon, Nov 23, 2015 at 1:58 AM, Peter UhnÃ¡k > <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>> wrote: > > > The question now is: what do we need to fix to make it work? Rewrite all internal links to use https when served over https Stephan

Nov. 23, 2015

Re: [Pharo-dev] Digest from slack to the mailing list?

by EuanM

I agree - if we can have each 24 hours of chat archived to somewhere that provides a free-text search, that would be very good. Up until now, I've been grabbing, editting and posting chats I find of interest and importance to me. And it seems to lend itself to design discussions. What it's not very good at, atm, is discussion threading. It would be great to be able to set your typing as belonging to a thread., so that when it get sucked out and archived that the threads were segregated. Does someone have a server that could receive a text dump of all recent Slack messages every 12 (or 24, or 6) hours, and then make it available for indexing by Google et al, and querying (via the search engines) by our dev base? On 22 November 2015 at 13:57, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Just to clear something up , because I see people in slack saying goodbye, > or "I cant reply right now I have something to do" . Slack is not just a > real time chat, it keeps messages inside a history of 10 thousand messages. > So that means you can log in Slack at any time and not lose a message. There > is no reason for you to be online all time, no reason to say goodbye, > goodmorning , goodafternoon. You can come and go as you please the exact > same way as the mailing list. > > The problem arises when we exceed 10k messages, the old ones get lost and I > think having a place to store them is a good idea. > > Also what is important is in the eye of the beholder, for example I dont > care about any discussion about web development , its just does not interest > me or database coding or many other things. I have learned to filter out the > messages I dont care about in the mailing list and just reject them. Slack > is same story, I quickly glance through its history and I can search the > messages that interest me using the search bar , I can star messages that I > want to keep, and I can comment on existing messages / code snippets which > create a thread about that message. > > In the end its impossible to keep the community in one place but to have a > central hub that collects all the little gems can be quite useful. > > On Sun, Nov 22, 2015 at 3:46 PM stepharo <stepharo(a)free.fr> wrote: >> >> Yes this would be good. >> People should understand that important discussions should be via the >> mailing-list. >> Emails are good because you can consume them the way you want. >> I simply cannot be connected all the time. So emails are good because I >> can process them >> when I decide. >> Slack is good for more interactive session around debugger and things >> like that. >> >> Stef >> >> >> Le 21/11/15 18:05, Stephan Eggermont a Ã©crit : >> > Should we have a digest from slack to a mailing list? >> > We are already losing messages >> > >> > Stephan >> > >> > >> > >> >> >

Nov. 22, 2015

Re: [Pharo-dev] Does Pharo stores original author of methods?

by EuanM

Is there any reason against amending Monticello to store and save all author's names? Presumably, we'd also want a tool that could extract amnders' names all the way back to the first commit of a package? How many on-line Monticello repositories are in common use? (I know of SqueakSource.com, Smalltalkhub.com and SqueakSource3) Are there active administrators for each of those repositories that would allow us to update the repositories to use the updated Monticello? On 22 November 2015 at 15:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 20 Nov 2015, at 14:35, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2015-11-20 14:21 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> epicea data is not stored forever. It is seasion based and the shipped >> image is >> clean. > > > But current source of this info is changes file (maybe sources). And I > remember you planned to store current sources in image. And such information > can be there too. > Maybe I miss something? > > > The original author is not really that much of information. And storing it > for every method in the image would take space. > > As I said: the whole idea of using a source revision control system is that > you have the *complete* history available, but > not wasting RAM. > > Marcus

Nov. 22, 2015

Re: [Pharo-dev] red banner and links with safari?

by Ben Coman

I guess the only real fix for the https pages produced to reference https stylesheets. cheers -ben On Mon, Nov 23, 2015 at 1:58 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > The question now is: what do we need to fix to make it work? > > > â > (or just open console in your favorite browser (chrome)) > > Peter >

Nov. 22, 2015

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

by Mariano Martinez Peck

> > >> >> Yes. I think it is possible to work around it by using the >> dictionary itself, storing the node selector in it in the replace: >> pattern and retrieving it in the with: pattern. >> >> rewriter >> replace: ('`#oldSelector `{:node :dic | (node value >> isSymbol and: [node value matchesRegex: ''.*oldSelector.*'']) >> ifTrue: [dic at: #selector put: node value. true] ifFalse: [false] }') >> with: ('`{:dic | RBLiteralNode value: ((dic at: >> #selector) copyReplaceAll: ''oldSelector'' with: ''newSelector'') >> asSymbol }'). >> >> >> Wow, that's very cool. I wasn't aware that I could pass arguments (like >> the dict in this case). This is powerful. >> > > Yes, quite significant. Also the fact the dictionary is cleared for each > match (so that it can be reused for the next match in the same ast). > > awesome. > Thank you RB Jedi. >> > > I've had the guidance of John Brant (and spent some time over the SmaCC > code where he uses it)... > > Now, maybe correcting RB in Gemstone is something to do, as well. >> >> >> Yes. So with the dict workaround you said, it DID work, but when I >> continue a little more and I found out where was the closure being >> generated, and that is RBPatternBlockNode >> #createBlockFor: >> And yeah, the way it was being generated the closure ("source >> evalauted") was binding "self" to nil. I found a way to make it bind >> the real self and that worked too. So...time to fork RB for GemStone and >> commit the fix :) >> > > You're now the maintainer of RB for GemStone! Congratulations :) > > ahhahahaha. 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: :(* > 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. > 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. > > Thanks! >> > > You're welcome. You are giving opportunities to improve which is what I > need (need to practice, need to practice, need to practice...). > > ahahahahahha :) > I have ideas for Mark Rizun's tool, but I don't have the time to work on > them. > > Thierry > > Thanks ! -- Mariano http://marianopeck.wordpress.com

Nov. 22, 2015

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

by Thierry Goubier

Le 22/11/2015 19:56, Mariano Martinez Peck a Ã©crit : > > > On Sat, Nov 21, 2015 at 7:07 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Mariano, > > Le 20/11/2015 20:58, Mariano Martinez Peck a Ã©crit : > > Thierry, > > Sorry to bother again. Unfortunately, RB does not work out of > the box in > GemStone .... only the formatter part. grrr. > > > There is maybe a message to send to the maintainer of RB in Gemstone :) > > > Thanks Thierry. Yes, I talked with Dale and the only "official" > usage/port of RB is actually the formatter ;) :( > Anyway, I am trying to make it work, and it's failing in this > easy example: > > /| tree rewriter |/ > /tree := RBParser parseMethod: 'DoIt ^ [:proxy | proxy at: > #oldSelector. > ]'./ > /rewriter := RBParseTreeRewriter new./ > /rewriter / > /replace: ('`#oldSelector `{:node | node value isSymbol and: > [node value > matchesRegex: ''.*oldSelector.*''] }')/ > /with: ('`{RBLiteralNode value: (`#oldSelector value copyReplaceAll: > ''oldSelector'' with: ''newSelector'') asSymbol }')./ > /rewriter executeTree: tree./ > /rewriter tree newSource/ > And the problem is the line: > > /with: ('`{RBLiteralNode value: (`#oldSelector value copyReplaceAll: > ''oldSelector'' with: ''newSelector'') asSymbol }')./ > > which gets translated to: > > [ :aDictionary | > RBLiteralNode > value: > ((*self* lookupMatchFor: '`#oldSelector' in: aDictionary) > value > copyReplaceAll: 'oldSelector' > with: 'newSelector') asSymbol ] > > The problem in GemStone is that that "self" is binded to nil and > not to > the receiver instance (RBPatternBlockNode). And so I get a Nil dnu.. > *And I don't know how that closure is finally generated.* > > The message node: > > /(*self* lookupMatchFor: '`#oldSelector' in: aDictionary) / > > Its generated in: > > RBPatternBlockNode >> constructLookupNodeFor: aString in: > aRBBlockNode > | argumentNode | > argumentNode := RBLiteralNode value: aString. > > ^RBMessageNode > receiver:* (RBVariableNode named: 'self')* > selector: #lookupMatchFor:in: > arguments: (Array with: argumentNode with: aRBBlockNode > arguments last) > > Any ideas? > > > Yes. I think it is possible to work around it by using the > dictionary itself, storing the node selector in it in the replace: > pattern and retrieving it in the with: pattern. > > rewriter > replace: ('`#oldSelector `{:node :dic | (node value > isSymbol and: [node value matchesRegex: ''.*oldSelector.*'']) > ifTrue: [dic at: #selector put: node value. true] ifFalse: [false] }') > with: ('`{:dic | RBLiteralNode value: ((dic at: > #selector) copyReplaceAll: ''oldSelector'' with: ''newSelector'') > asSymbol }'). > > > Wow, that's very cool. I wasn't aware that I could pass arguments (like > the dict in this case). This is powerful. Yes, quite significant. Also the fact the dictionary is cleared for each match (so that it can be reused for the next match in the same ast). > Thank you RB Jedi. I've had the guidance of John Brant (and spent some time over the SmaCC code where he uses it)... > Now, maybe correcting RB in Gemstone is something to do, as well. > > > Yes. So with the dict workaround you said, it DID work, but when I > continue a little more and I found out where was the closure being > generated, and that is RBPatternBlockNode >> #createBlockFor: > And yeah, the way it was being generated the closure ("source > evalauted") was binding "self" to nil. I found a way to make it bind > the real self and that worked too. So...time to fork RB for GemStone and > commit the fix :) You're now the maintainer of RB for GemStone! Congratulations :) > 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. 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! You're welcome. You are giving opportunities to improve which is what I need (need to practice, need to practice, need to practice...). I have ideas for Mark Rizun's tool, but I don't have the time to work on them. Thierry

Nov. 22, 2015

Re: [Pharo-dev] Rules

by Yuriy Tymchuk

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

Nov. 22, 2015

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

by Mariano Martinez Peck

On Sat, Nov 21, 2015 at 7:07 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi Mariano, > > Le 20/11/2015 20:58, Mariano Martinez Peck a Ã©crit : > >> Thierry, >> >> Sorry to bother again. Unfortunately, RB does not work out of the box in >> GemStone .... only the formatter part. grrr. >> > > There is maybe a message to send to the maintainer of RB in Gemstone :) > > Thanks Thierry. Yes, I talked with Dale and the only "official" usage/port of RB is actually the formatter ;) > Anyway, I am trying to make it work, and it's failing in this easy example: >> >> /| tree rewriter |/ >> /tree := RBParser parseMethod: 'DoIt ^ [:proxy | proxy at: #oldSelector. >> ]'./ >> /rewriter := RBParseTreeRewriter new./ >> /rewriter / >> /replace: ('`#oldSelector `{:node | node value isSymbol and: [node value >> matchesRegex: ''.*oldSelector.*''] }')/ >> /with: ('`{RBLiteralNode value: (`#oldSelector value copyReplaceAll: >> ''oldSelector'' with: ''newSelector'') asSymbol }')./ >> /rewriter executeTree: tree./ >> /rewriter tree newSource/ >> And the problem is the line: >> >> /with: ('`{RBLiteralNode value: (`#oldSelector value copyReplaceAll: >> ''oldSelector'' with: ''newSelector'') asSymbol }')./ >> >> which gets translated to: >> >> [ :aDictionary | >> RBLiteralNode >> value: >> ((*self* lookupMatchFor: '`#oldSelector' in: aDictionary) value >> copyReplaceAll: 'oldSelector' >> with: 'newSelector') asSymbol ] >> >> The problem in GemStone is that that "self" is binded to nil and not to >> the receiver instance (RBPatternBlockNode). And so I get a Nil dnu.. >> *And I don't know how that closure is finally generated.* >> >> The message node: >> >> /(*self* lookupMatchFor: '`#oldSelector' in: aDictionary) / >> >> Its generated in: >> >> RBPatternBlockNode >> constructLookupNodeFor: aString in: aRBBlockNode >> | argumentNode | >> argumentNode := RBLiteralNode value: aString. >> >> ^RBMessageNode >> receiver:* (RBVariableNode named: 'self')* >> selector: #lookupMatchFor:in: >> arguments: (Array with: argumentNode with: aRBBlockNode arguments last) >> >> Any ideas? >> > > Yes. I think it is possible to work around it by using the dictionary > itself, storing the node selector in it in the replace: pattern and > retrieving it in the with: pattern. > > rewriter > replace: ('`#oldSelector `{:node :dic | (node value > isSymbol and: [node value matchesRegex: ''.*oldSelector.*'']) ifTrue: [dic > at: #selector put: node value. true] ifFalse: [false] }') > with: ('`{:dic | RBLiteralNode value: ((dic at: #selector) > copyReplaceAll: ''oldSelector'' with: ''newSelector'') asSymbol }'). > > Wow, that's very cool. I wasn't aware that I could pass arguments (like the dict in this case). This is powerful. Thank you RB Jedi. > Now, maybe correcting RB in Gemstone is something to do, as well. > > Yes. So with the dict workaround you said, it DID work, but when I continue a little more and I found out where was the closure being generated, and that is RBPatternBlockNode >> #createBlockFor: And yeah, the way it was being generated the closure ("source evalauted") was binding "self" to nil. I found a way to make it bind the real self and that worked too. So...time to fork RB for GemStone and commit the fix :) BTW, do you image other cases like this? Thanks! Regards, > > Thierry > > thanks in advance, >> >> >> On Mon, Nov 9, 2015 at 2:39 PM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 09/11/2015 17:38, Mariano Martinez Peck a Ã©crit : >> >> Thierry, I have a last question. My last requirement will >> basically be >> to find ANY node that would match the regex *oldSelector* and >> rename it >> to *newSelector* being that.. a literal string, a literal symbol, >> a >> message send, a tempVar name, a comment, etc... I guess there is a >> simpler way that defining rewrite for each type of node right? >> I can always do a "(methodSource substrings detect: [:each | each >> matches: '*oldSelector'] ifNone: [#()] ) each2: [:each2 | >> copReplace. >> .... ] >> >> >> I think that if it is really everywhere, then it may works better to >> just do text replace (methodSource copyReplaceAll: 'oldSelector' >> with: 'newSelector'). >> >> But remember that it will touch everything (pragmas, varNames, >> comments, etc.) >> >> but RB is probably better. >> >> >> It gives you more control to what you will change. But then you will >> have to write rewrites for all types of nodes (around 6 or 7?). >> >> Any clues in this last requirement? >> >> >> Well, one thing which may be interesting would be to consider >> encapsulating the rewrites in refactoring commands, and bring them >> as a composite change, so that you could launch a rewrite, recover >> all those method changes, apply (execute) them, check the result >> with the possibility of undoing them. >> >> But I'm not familiar with that part of RB. I do consider it could >> become significant with EPICEA. It has been a long term project to >> have AltBrowser make all coding actions as refactoring commands so >> that EPICEA could log them properly, but its only partly there (and >> has been for years now)... and EPICEA is not yet here as well (but >> could be soon). >> >> Thierry >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > -- Mariano http://marianopeck.wordpress.com

Nov. 22, 2015

Re: [Pharo-dev] Rules

by Peter UhnÃ¡k

>> printOn: aStream >> super printOn: aStream >> aStream nextPutAll: '(', faces printString , ')' Because you forgot dot after the first line. This is why I always use autoformatting to catch these kind of stupid mistakes (happens to me a lot).

Nov. 22, 2015

Jenkins job @ ci.inria.fr

by Lucas Godoy

Hi everyone I have two jobs in ci.inria.fr for the project Tracks. One is for Pharo 3.0 and another for Pharo 4.0. Since Tracks requires Epicea to run and Epicea is no longer mantained for Pharo 3.0, the Tracks job for Pharo 3.0 is failing and it doesn't make sense to keep it. I only want to keep the job for Pharo 4.0. This is the URL of the job: <http://goog_1488548907> https://ci.inria.fr/pharo-contribution/job/Tracks/PHARO=30,VERSION=developm… I haven't logged-in in Jenkins in quite a while and now my authentication fails. I may have just forgotten my password or my credentials are expired. Can somebody at INRIA delete the Tracks job for Pharo 3.0 or reset my password so I can delete it, please? Thanks in advance! -- ------------------------------------------ Lucas Godoy ------------------------------------------

Nov. 22, 2015