- Pharo-users - lists.pharo.org

Re: [Pharo-users] On Class and Method comments

by stepharo

> I really like to start writing some class and method comments to make > Pharo image more beginner friendly. This would be realllllllllly coool. Did you check the class comment template because I wrote it thinking about this. What I think would be great is to have great comments for the basic classes. Because as a newby such classes are really important. For example I would like to enhance the symbol class comment to include the snippet sent by henrik | s1 s2 | s1 := 1234 asString. s2 := 1234 asString. s1 = s2. "true" s1 == s2. "false" s1 asSymbol = s2 asSymbol. "true" s1 asSymbol == s2 asSymbol. "true" (s1 class allInstances select: [:s | s = s1 ]) size. "2" (s1 asSymbol class allInstances select: [:s | s = s1 asSymbol ]) size. "1" [ #stringA = #stringB ] bench. "26,812,864 per second" [ 'StringA' = 'StringB' ] bench. "3,492,987 per second" > Are there any guidelines when and how to comment classes and methods ? > What about inline comments ?

May 17, 2016

Re: [Pharo-users] Retina support in Pharo

by stepharo

> I am about to buy a new laptop. Pharo does not work with Retina display? > How can it be? Alexandre I'm sorry to see this email. We all worked like mad and Esteban did A MASSIVE AMOUNT OF WORK. Nearly nobody on this list really understand what is to write a new FFI framework and Esteban got nearly burnt by Spur and by UFFI. It was not our plan to get forced to do such tasks. So Esteban did not time to work on Retina support. It looks quite simple to me. Now what all pharoers should deeply understand is that if - people would not only focus on their projects (even if they are important) but help with pharo issues, then core engineers would have more time for the things that others cannot do. Easy no. - the pharo consortium does not raise enough money we will not be able to pay Esteban in the future. So enjoy this moment because we have Esteban on managing releases and all the dirty work Nicolas Passerini payed by the consortium for 9 months to work on Git support Pavel to work on bootstrap, bugfixes and pharo distributions Christophe Demarey 60% on bootstrap and pharo package manager Guillermo 60% on bootstrap and others And this will not be forever. Stef > > Alexandre > > >> On May 17, 2016, at 2:13 PM, Luis Felipe Strano Moraes <luis.strano(a)gmail.com> wrote: >> >> I asked about this just a few days ago, here's the reply: >> >> http://forum.world.st/Pharo-and-HiDPI-tc4894853.html >> >> >> >> On Mon, May 16, 2016 at 10:37 PM, markm <mjmzen(a)gmail.com> wrote: >> Hi >> >> Is it possible to get Pharo (4 or 5) to run with retina support on OS X? I >> have tried searching for some answers, but alas could only find a handful of >> posts from a few years back. >> >> Any help much appreciated! >> >> >> Mark >> >> >> >> -- >> View this message in context: http://forum.world.st/Retina-support-in-Pharo-tp4895245.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> >> >> -- >> LuÃs Felipe Strano Moraes >> http://www.strano.org

May 17, 2016

Re: [Pharo-users] Retina support in Pharo

by Esteban Lorenzano

it works. just fonts could be better (and eventually, they will). Esteban > On 17 May 2016, at 21:32, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > I am about to buy a new laptop. Pharo does not work with Retina display? > How can it be? > > Alexandre > > >> On May 17, 2016, at 2:13 PM, Luis Felipe Strano Moraes <luis.strano(a)gmail.com> wrote: >> >> I asked about this just a few days ago, here's the reply: >> >> http://forum.world.st/Pharo-and-HiDPI-tc4894853.html >> >> >> >> On Mon, May 16, 2016 at 10:37 PM, markm <mjmzen(a)gmail.com> wrote: >> Hi >> >> Is it possible to get Pharo (4 or 5) to run with retina support on OS X? I >> have tried searching for some answers, but alas could only find a handful of >> posts from a few years back. >> >> Any help much appreciated! >> >> >> Mark >> >> >> >> -- >> View this message in context: http://forum.world.st/Retina-support-in-Pharo-tp4895245.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> >> >> -- >> LuÃs Felipe Strano Moraes >> http://www.strano.org > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

May 17, 2016

Re: [Pharo-users] Retina support in Pharo

by Alexandre Bergel

I am about to buy a new laptop. Pharo does not work with Retina display? How can it be? Alexandre > On May 17, 2016, at 2:13 PM, Luis Felipe Strano Moraes <luis.strano(a)gmail.com> wrote: > > I asked about this just a few days ago, here's the reply: > > http://forum.world.st/Pharo-and-HiDPI-tc4894853.html > > > > On Mon, May 16, 2016 at 10:37 PM, markm <mjmzen(a)gmail.com> wrote: > Hi > > Is it possible to get Pharo (4 or 5) to run with retina support on OS X? I > have tried searching for some answers, but alas could only find a handful of > posts from a few years back. > > Any help much appreciated! > > > Mark > > > > -- > View this message in context: http://forum.world.st/Retina-support-in-Pharo-tp4895245.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > -- > LuÃs Felipe Strano Moraes > http://www.strano.org -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 17, 2016

Re: [Pharo-users] On Class and Method comments

by Dimitris Chloupis

The problem I have with braking methods to much smaller ones is that it makes browsing code far more tedious. I think the 10 lines limit is fine but once you get 5 lines it becomes unnecessarily modular. I think like all things comments and braking methods should be exercised with some critical thinking. I also dont see the big deal of commenting your classes and at least a few key methods. In any case, complaining leads nowhere, my question was merely to help out with the comments. If you ask me and you have not , pharo would be cool to have a modular system where someone can hide and unhide comments or have summary comments and detailed comments , so that we integrate documentation inside the image. Maybe one day I will be able to tackle this as well. On Tue, May 17, 2016 at 9:07 PM Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > You are absolutely right. Many without comments. Some of which may not > need comments as they are self revealing in what and why. But many which do > need some good comments. > > As I read Peter's email. What he was saying is that my intent or why can > be placed in the method comment when broken into smaller methods. Instead > of it being inline in a larger method. Sometimes that is true. > > What I am encountering sometimes at the moment in parsing the XML is ugly > XML source. I have methods with way too many ifTrue: [] ifFalse: [ ifTrue: > [] ifFalse: []] ... nested conditionals. Sometimes this is not easy to > break up into smaller methods. All of the state is in the nested > conditionals. > > In this situation it is occurring as I parse the 16MB XML file and > encounter situations in the source. The debugger pops up. I have to deal > with whatever. Sometimes this needs some inline comments. Sometimes after I > have the code working. I may or may not be able to reasonably refactor into > something nicer and cleaner. Sometimes it is more important to move on to > other more pressing issues. > > Sometimes I think this why we have uncommented or poorly commented code in > the image. It is working. I need to move on. Really we want some of the big > movers to have this liberty. And allow some of us to follow behind, learn > and comment. > > Thank you for this effort to help improve our home (image). :) > I need to find time and learn to contribute also. > > > Jimmie > > > > On 05/17/2016 11:59 AM, Dimitris Chloupis wrote: > > ok guys then it seems all is as expected > > I am a fan of inline comments when needed, I am with full agreement with > Jimmie here , braking methods to smaller methods cannot reveal intend, an > inline comment can but thats not big deal i can put everything on the start > so everyone is happy > > The problem here is that there many classes with no comments and methods > that inline comments is the least of my worries. > > On Tue, May 17, 2016 at 7:20 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> >> Now, I only know that comments in block closures are placed behind the >>> block code. >>> Do you know more examplmes where the formatter still misplaces the >>> comment. >> >> >> Maybe just comments now? I've added a formatting configuration that >> preserved vertical white space (and I believe also comment position, >> because I used to write inline comments), but I think it was lost during >> migration to BlueInk. But I'll have a look. >> >> >> On Tue, May 17, 2016 at 5:32 PM, Jimmie Houchin <jlhouchin(a)gmail.com> >> wrote: >> >>> On 05/17/2016 01:40 AM, Peter UhnÃ¡k wrote: >>> >>> As a note, maybe try to avoid inline comments unless formatter is fixed, >>> because autoformatting _will_ misplace them. (Not to mention that imho >>> inline comments in Smalltalk are a result of a bad designâ¦ if you need an >>> inline comment, maybe turn that into actual code). >>> >>> >>> I disagree with the comment about inline comments being bad design. At >>> least as a broadly applied as the above was. >>> >>> Comments often say "Why" we did something. Code says "How" or "What" we >>> are doing. I have encountered many times where if I did not have a comment >>> for the "Why". Then at a later date when I don't remember the "Why". I >>> encounter code that looks strange and I am tempted to refactor and >>> consequently would introduce bugs. >>> >> >> This doesn't necessarily dispute my point. If you need to have inline >> comments then you are most likely doing in the method more then you should, >> otherwise you can just put the intent in the method comment. >> Of course in real world we have looooong methods in both ancient and >> (unfortunately) new systems, and adding a comment is better then nothing. >> Assuming of course, that the comment is correctâ¦ because a wrong or >> misleading comment can do more harm than goodâ¦ that's why I _personally_ >> (thus the imho in the original note) prefer code over comments. Because >> code is what actually happens. >> >> And finally I rarely (unless the method is a real mess) have problem >> understanding a single method (I can poke it, look at tests, go through the >> code, ...). What I usually lack is high-level overview that would tell me >> how the system overall works. That you cannot read from method (or class) >> comments. >> >> >> >>> Right now I am working on parsing a bunch of xml files. Third party data >>> sources. >>> >> >> Is it XML or XMI? Couple of weeks back a wrote a simple utility >> for Synectique to help with analyzing and processing XMI files. Maybe it >> could help you a bit https://github.com/peteruhnak/xmi-analyzer ? >> >> >>> There is ugliness in the world. I have to clean the ugliness in order to >>> be able to parse the files. There is no option if I want to do this. I have >>> no control over the sources. I am not interested in engaging outside >>> bureaucratic policies and people in order to change their procedures and >>> policies so that I can have better sources. How often would I be willing to >>> fight this losing battle. >>> >>> The only solution is to do ugly things, for good reasons and comment >>> them well. So that I know not just what I did, but why. >>> >>> I also believe there is some conflicting policy in the code critic or >>> whatever is telling me my method is too long. >>> >>> I have frequently written methods that had a few temp vars with nice >>> informative names. and the method is involved enough to use these vars >>> multiple times. I get this nice information informing me my method is long. >>> Or in Pharo4 going yellow and then red. :) >>> >>> However many times if I made these vars short, like x, y, z. Then the >>> method is a perfectly fine length. Ugh. I am then being punished for length >>> of names. I have seen this a lot. >>> >> >> Well Code Critic doesn't force you to do all these things. But every time >> you transgress the rule you should consider whether it's worth it. (And >> maybe even auto-ignore the rule.) >> >> >>> In any case, there are no guidelines afaikâ¦ otherwise we would have >>> comments everywhere already. :) >>> >>> >>> Not necessarily. People are busy. Sometimes getting working code out is >>> more important than commenting it well. >>> >>> For example. And I am not saying this is true. It is simply and example. >>> While pressure is mounting to release Pharo 5. The few over worked people >>> involved in that final process. Finishing up the final things, might be >>> pragmatic and let working code go without comments. Or in some similar >>> situation by a code contributor. >>> >>> Then their are people like myself and Dimitris who might not feel >>> confident in submitting comments for some of these areas without >>> appropriate guidelines. We want to improve the situation not make bad >>> examples of what not to do. :) >>> >>> Just some of my opinions. >>> >> >> >> And finally there is never one rule that would fit all, and any guideline >> or whatever will find an edge case. But Pharo is moving fastâ¦ so I don't >> see why you wouldn't feel confident about commenting. The worst case >> scenario is that something breaks and we have a chance to learn something >> from the mistake. >> >> Peter >> >> >>> >>> >>> Jimmie >>> >>> >>> Perhaps one thing regarding class comments: There was a push to use >>> PIllar there if you need formatting, but I am not sure what is the current >>> status of that. >>> >>> Peter >>> >>> On Tue, May 17, 2016 at 12:04 AM, Dimitris Chloupis < >>> kilon.alios(a)gmail.com> wrote: >>> >>>> I really like to start writing some class and method comments to make >>>> Pharo image more beginner friendly. Are there any guidelines when and how >>>> to comment classes and methods ? What about inline comments ? >>>> >>> >>> >>> >

May 17, 2016

Re: [Pharo-users] Retina support in Pharo

by Luis Felipe Strano Moraes

I asked about this just a few days ago, here's the reply: http://forum.world.st/Pharo-and-HiDPI-tc4894853.html On Mon, May 16, 2016 at 10:37 PM, markm <mjmzen(a)gmail.com> wrote: > Hi > > Is it possible to get Pharo (4 or 5) to run with retina support on OS X? I > have tried searching for some answers, but alas could only find a handful > of > posts from a few years back. > > Any help much appreciated! > > > Mark > > > > -- > View this message in context: > http://forum.world.st/Retina-support-in-Pharo-tp4895245.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- LuÃs Felipe Strano Moraes http://www.strano.org

May 17, 2016

Re: [Pharo-users] On Class and Method comments

by Jimmie Houchin

You are absolutely right. Many without comments. Some of which may not need comments as they are self revealing in what and why. But many which do need some good comments. As I read Peter's email. What he was saying is that my intent or why can be placed in the method comment when broken into smaller methods. Instead of it being inline in a larger method. Sometimes that is true. What I am encountering sometimes at the moment in parsing the XML is ugly XML source. I have methods with way too many ifTrue: [] ifFalse: [ ifTrue: [] ifFalse: []] ... nested conditionals. Sometimes this is not easy to break up into smaller methods. All of the state is in the nested conditionals. In this situation it is occurring as I parse the 16MB XML file and encounter situations in the source. The debugger pops up. I have to deal with whatever. Sometimes this needs some inline comments. Sometimes after I have the code working. I may or may not be able to reasonably refactor into something nicer and cleaner. Sometimes it is more important to move on to other more pressing issues. Sometimes I think this why we have uncommented or poorly commented code in the image. It is working. I need to move on. Really we want some of the big movers to have this liberty. And allow some of us to follow behind, learn and comment. Thank you for this effort to help improve our home (image). :) I need to find time and learn to contribute also. Jimmie On 05/17/2016 11:59 AM, Dimitris Chloupis wrote: > ok guys then it seems all is as expected > > I am a fan of inline comments when needed, I am with full agreement > with Jimmie here , braking methods to smaller methods cannot reveal > intend, an inline comment can but thats not big deal i can put > everything on the start so everyone is happy > > The problem here is that there many classes with no comments and > methods that inline comments is the least of my worries. > > On Tue, May 17, 2016 at 7:20 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com>> wrote: > > > Now, I only know that comments in block closures are placed > behind the block code. > Do you know more examplmes where the formatter still misplaces > the comment. > > > Maybe just comments now? I've added a formatting configuration > that preserved vertical white space (and I believe also comment > position, because I used to write inline comments), but I think it > was lost during migration to BlueInk. But I'll have a look. > > On Tue, May 17, 2016 at 5:32 PM, Jimmie Houchin > <jlhouchin(a)gmail.com <mailto:jlhouchin@gmail.com>> wrote: > > On 05/17/2016 01:40 AM, Peter UhnÃ¡k wrote: >> As a note, maybe try to avoid inline comments unless >> formatter is fixed, because autoformatting _will_ misplace >> them. (Not to mention that imho inline comments in Smalltalk >> are a result of a bad designâ¦ if you need an inline comment, >> maybe turn that into actual code). > > I disagree with the comment about inline comments being bad > design. At least as a broadly applied as the above was. > > Comments often say "Why" we did something. Code says "How" or > "What" we are doing. I have encountered many times where if I > did not have a comment for the "Why". Then at a later date > when I don't remember the "Why". I encounter code that looks > strange and I am tempted to refactor and consequently would > introduce bugs. > > > This doesn't necessarily dispute my point. If you need to have > inline comments then you are most likely doing in the method more > then you should, otherwise you can just put the intent in the > method comment. > Of course in real world we have looooong methods in both ancient > and (unfortunately) new systems, and adding a comment is better > then nothing. > Assuming of course, that the comment is correctâ¦ because a wrong > or misleading comment can do more harm than goodâ¦ that's why I > _personally_ (thus the imho in the original note) prefer code over > comments. Because code is what actually happens. > > And finally I rarely (unless the method is a real mess) have > problem understanding a single method (I can poke it, look at > tests, go through the code, ...). What I usually lack is > high-level overview that would tell me how the system overall > works. That you cannot read from method (or class) comments. > > Right now I am working on parsing a bunch of xml files. Third > party data sources. > > > Is it XML or XMI? Couple of weeks back a wrote a simple utility > for Synectique to help with analyzing and processing XMI files. > Maybe it could help you a bit > https://github.com/peteruhnak/xmi-analyzer ? > > There is ugliness in the world. I have to clean the ugliness > in order to be able to parse the files. There is no option if > I want to do this. I have no control over the sources. I am > not interested in engaging outside bureaucratic policies and > people in order to change their procedures and policies so > that I can have better sources. How often would I be willing > to fight this losing battle. > > The only solution is to do ugly things, for good reasons and > comment them well. So that I know not just what I did, but why. > > I also believe there is some conflicting policy in the code > critic or whatever is telling me my method is too long. > > I have frequently written methods that had a few temp vars > with nice informative names. and the method is involved enough > to use these vars multiple times. I get this nice information > informing me my method is long. Or in Pharo4 going yellow and > then red. :) > > However many times if I made these vars short, like x, y, z. > Then the method is a perfectly fine length. Ugh. I am then > being punished for length of names. I have seen this a lot. > > > Well Code Critic doesn't force you to do all these things. But > every time you transgress the rule you should consider whether > it's worth it. (And maybe even auto-ignore the rule.) > >> In any case, there are no guidelines afaikâ¦ otherwise we >> would have comments everywhere already. :) > > Not necessarily. People are busy. Sometimes getting working > code out is more important than commenting it well. > > For example. And I am not saying this is true. It is simply > and example. While pressure is mounting to release Pharo 5. > The few over worked people involved in that final process. > Finishing up the final things, might be pragmatic and let > working code go without comments. Or in some similar situation > by a code contributor. > > Then their are people like myself and Dimitris who might not > feel confident in submitting comments for some of these areas > without appropriate guidelines. We want to improve the > situation not make bad examples of what not to do. :) > > Just some of my opinions. > > > > And finally there is never one rule that would fit all, and any > guideline or whatever will find an edge case. But Pharo is moving > fastâ¦ so I don't see why you wouldn't feel confident about > commenting. The worst case scenario is that something breaks and > we have a chance to learn something from the mistake. > > Peter > > > > Jimmie > > >> Perhaps one thing regarding class comments: There was a push >> to use PIllar there if you need formatting, but I am not sure >> what is the current status of that. >> >> Peter >> >> On Tue, May 17, 2016 at 12:04 AM, Dimitris Chloupis >> <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> I really like to start writing some class and method >> comments to make Pharo image more beginner friendly. Are >> there any guidelines when and how to comment classes and >> methods ? What about inline comments ? >> >> >

May 17, 2016

Re: [Pharo-users] On Class and Method comments

by Dimitris Chloupis

ok guys then it seems all is as expected I am a fan of inline comments when needed, I am with full agreement with Jimmie here , braking methods to smaller methods cannot reveal intend, an inline comment can but thats not big deal i can put everything on the start so everyone is happy The problem here is that there many classes with no comments and methods that inline comments is the least of my worries. On Tue, May 17, 2016 at 7:20 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Now, I only know that comments in block closures are placed behind the >> block code. >> Do you know more examplmes where the formatter still misplaces the >> comment. > > > Maybe just comments now? I've added a formatting configuration that > preserved vertical white space (and I believe also comment position, > because I used to write inline comments), but I think it was lost during > migration to BlueInk. But I'll have a look. > > > On Tue, May 17, 2016 at 5:32 PM, Jimmie Houchin <jlhouchin(a)gmail.com> > wrote: > >> On 05/17/2016 01:40 AM, Peter UhnÃ¡k wrote: >> >> As a note, maybe try to avoid inline comments unless formatter is fixed, >> because autoformatting _will_ misplace them. (Not to mention that imho >> inline comments in Smalltalk are a result of a bad designâ¦ if you need an >> inline comment, maybe turn that into actual code). >> >> >> I disagree with the comment about inline comments being bad design. At >> least as a broadly applied as the above was. >> >> Comments often say "Why" we did something. Code says "How" or "What" we >> are doing. I have encountered many times where if I did not have a comment >> for the "Why". Then at a later date when I don't remember the "Why". I >> encounter code that looks strange and I am tempted to refactor and >> consequently would introduce bugs. >> > > This doesn't necessarily dispute my point. If you need to have inline > comments then you are most likely doing in the method more then you should, > otherwise you can just put the intent in the method comment. > Of course in real world we have looooong methods in both ancient and > (unfortunately) new systems, and adding a comment is better then nothing. > Assuming of course, that the comment is correctâ¦ because a wrong or > misleading comment can do more harm than goodâ¦ that's why I _personally_ > (thus the imho in the original note) prefer code over comments. Because > code is what actually happens. > > And finally I rarely (unless the method is a real mess) have problem > understanding a single method (I can poke it, look at tests, go through the > code, ...). What I usually lack is high-level overview that would tell me > how the system overall works. That you cannot read from method (or class) > comments. > > > >> Right now I am working on parsing a bunch of xml files. Third party data >> sources. >> > > Is it XML or XMI? Couple of weeks back a wrote a simple utility > for Synectique to help with analyzing and processing XMI files. Maybe it > could help you a bit https://github.com/peteruhnak/xmi-analyzer ? > > >> There is ugliness in the world. I have to clean the ugliness in order to >> be able to parse the files. There is no option if I want to do this. I have >> no control over the sources. I am not interested in engaging outside >> bureaucratic policies and people in order to change their procedures and >> policies so that I can have better sources. How often would I be willing to >> fight this losing battle. >> >> The only solution is to do ugly things, for good reasons and comment them >> well. So that I know not just what I did, but why. >> >> I also believe there is some conflicting policy in the code critic or >> whatever is telling me my method is too long. >> >> I have frequently written methods that had a few temp vars with nice >> informative names. and the method is involved enough to use these vars >> multiple times. I get this nice information informing me my method is long. >> Or in Pharo4 going yellow and then red. :) >> >> However many times if I made these vars short, like x, y, z. Then the >> method is a perfectly fine length. Ugh. I am then being punished for length >> of names. I have seen this a lot. >> > > Well Code Critic doesn't force you to do all these things. But every time > you transgress the rule you should consider whether it's worth it. (And > maybe even auto-ignore the rule.) > > >> In any case, there are no guidelines afaikâ¦ otherwise we would have >> comments everywhere already. :) >> >> >> Not necessarily. People are busy. Sometimes getting working code out is >> more important than commenting it well. >> >> For example. And I am not saying this is true. It is simply and example. >> While pressure is mounting to release Pharo 5. The few over worked people >> involved in that final process. Finishing up the final things, might be >> pragmatic and let working code go without comments. Or in some similar >> situation by a code contributor. >> >> Then their are people like myself and Dimitris who might not feel >> confident in submitting comments for some of these areas without >> appropriate guidelines. We want to improve the situation not make bad >> examples of what not to do. :) >> >> Just some of my opinions. >> > > > And finally there is never one rule that would fit all, and any guideline > or whatever will find an edge case. But Pharo is moving fastâ¦ so I don't > see why you wouldn't feel confident about commenting. The worst case > scenario is that something breaks and we have a chance to learn something > from the mistake. > > Peter > > >> >> >> Jimmie >> >> >> Perhaps one thing regarding class comments: There was a push to use >> PIllar there if you need formatting, but I am not sure what is the current >> status of that. >> >> Peter >> >> On Tue, May 17, 2016 at 12:04 AM, Dimitris Chloupis < >> <kilon.alios(a)gmail.com>kilon.alios(a)gmail.com> wrote: >> >>> I really like to start writing some class and method comments to make >>> Pharo image more beginner friendly. Are there any guidelines when and how >>> to comment classes and methods ? What about inline comments ? >>> >> >> >>

May 17, 2016

Re: [Pharo-users] TextAction bugs

by Alistair Grant

On Mon, May 16, 2016 at 08:15:28PM +0200, stepharo wrote: > Hi all :) > > Hi All, > > > > TextAction appears to have a couple of issues: > > > > > > TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor > > "sent when a user clicks on a piece of text to which I am applied in an editor" > > > > "may be self is included in the event or an Object. " > > ^ actOnClickBlock cull: self cull: anEvent cull: anObject cull: paragraph cull: editor > To me this use of cull: is plain plain plain bad. > cull: is a plague. People use is far too often. > It indicates a lack of > - design > - object because with one object the block would get it and select what > is needed. +1 > - then I do not get why we need to pass the paragraph and the editor > > > #cull:cull:cull:cull:cull: doesn't exist, so should be something like: > > > > > > TextAction>>actOnClick: anEvent for: anObject in: paragraph editor: editor > > "sent when a user clicks on a piece of text to which I am applied in an editor" > > > > "may be self is included in the event or an Object. " > > ^ actOnClickBlock valueWithEnoughArguments: (Array with: self with: anEvent with: anObject with: paragraph with: editor) > > it looks already better. Slice submitted to Pharo60Inbox (issue 18200). Thanks for your positive feedback. Cheers, Alistair > > It is also missing the Rubric version: > > > > > > TextAction>>rubActOnClick: anEvent for: anObject in: paragraph editor: editor > > "sent when a user clicks on a piece of text to which I am applied in an editor" > > > > "may be self is included in the event or an Object. " > > ^ actOnClickBlock valueWithEnoughArguments: (Array with: self with: anEvent with: anObject with: paragraph with: editor) > > > > > > I've followed the convention in the other implementations of > > #rubActOnClick:for:in:editor: and reimplemented the code, but it could > > just as easily call #actOnClick:for:in:editor:. > > > > Any reason not to submit this as a formal bug report? > > > > Should it be submitted as two separate bug reports since they are in > > separate packages? > > > > Thanks! > > Alistair

May 17, 2016

Re: [Pharo-users] Spec layout

by Johan Fabry

Hi Marion, the class side message of defaultSpec is generally meant to be used if you use a fixed number of widgets, so you can put the reference to the name of each widget there (in cour case #buttons). For variable number of widgets you should have a look at the dynamic features of Spec. That being said, It looks like what you really want to use is a Radio Button Group. Have a look at RadioButtonGroupExample. HTH -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On May 17, 2016, at 13:48, Marion Noirbent <ms.noirbent(a)etudiant.univ-lille1.fr> wrote: > > Hi, > I'm trying to create a widget whith Spec, managing a collection of RadioButton. But I have a problem with defaultSpec (the accessor of the collection is the methods "buttons") : > > If i put defaultSpec on class side, i can't acces the collection of the instance. (the following code iterate on the string) > > defaultSpec > <spec: #default> > ^ SpecLayout composed > newColumn: [ :column | #buttons do: [ :item | column add: item ] ]; > yourself > > If i put it on instance side, the lookup don't find it (in the book Building UI with Spec, it said the lookup begin by the instance side and it allow to have specific UI, in part about layout) > > defaultSpec > <spec: #default> > ^ SpecLayout composed > newColumn: [ :column | self buttons do: [ :item | column add: item ] ]; > yourself > > Any idea ? > > Marion Noirbent, > >

May 17, 2016