May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] collaborActive book refers to SS

by Frank Shearar

On 16 May 2013 11:44, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > On May 16, 2013, at 12:13 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 16 May 2013 10:38, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >>> >>> On May 16, 2013, at 11:23 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> >>>> http://book.pharo-project.org/book/Tidbits/FAQ/Packages/ >>>> >>>> talks about how you can create a SqueakSource project. Presumably we >>>> want this to explain either how to create an SS3 project or a StHub >>>> project? >>>> >>>> If all I need to do is issue a pull request to >>>> https://github.com/SquareBracketAssociates/PharoByExample-english/ I'm >>>> happy to update it to whichever you prefer. >>> >>> please do :) >> >> I'm guessing you'd want to point to StHub? > > yes > >> (I use ss3 for everything, >> but it seems most of the Pharo devs are pushing for StHub.) > > Yes So I finally issued the pull request. There's still a reference to SMACC being hosted on SS. If the official repository has moved, or if Pharo's forked it to StHub, let me know and I'll update the PR accordingly. frank

May 18, 2013

Re: [Pharo-dev] Small Methods dont need comments , true or myth ?

by kilon

I happen to own that book so I did take a look at it last night and then another look and then another and was still not convinced. You see I am a practical person , and even though I am nowhere near to being a pro code I have my fair share of libraries and their design. The thing that I learned is what others may consider a good design , simple and easy to understand for me it becomes quite a problem and quite the opposite. Kent Becks makes the big assumption that people's brain work the same way. Just because he sees his methods and can immediately understand what they do because of a good design that does not apply for everyone. About having a specialized tool does not solve the problem its just makes it more tolerable. Its just like telling you that I wont remove the bugs from my programm instead I will give you a debugger so you can do it easier. It makes the big assumption that the developer really cares how the library works. He does not, only thing he wants is to use the library and in many cases not even the entire library just portions of it. What happens when he does not know what portions exactly to use to get the result he wants does he go through tracing every singe method ? Is this really simple coding ? For me small methods , EVERY method needs a comment , not because its that hard to read a few lines of code but because its plain simpler and faster. And the whole argument that comments are extra labor , yes its true , but one thing I have learned is coding is 99% reading and 1% about writting to use Kent Becks numbers. Unless you use libraries you already know where obviously you fall outside the scope of this discussion. I never saw documentation or writting comments as the time wasting that many coders see it. I find bug hunting way more troublesome. At least you confirmed my suspicion that this theory is based on the over confidence of code design. There is some truth into it of course , but its too unreliable at least for me. Thank you for taking the time to explain things to this detail I really appreciate it. -- View this message in context: http://forum.world.st/Pharo-dev-Small-Methods-dont-need-comments-true-or-my… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 18, 2013

Re: [Pharo-dev] 3.0 git tracker

by Frank Shearar

On 18 May 2013 10:04, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-18, at 10:53, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 18 May 2013 01:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> Pharo 3.0 is now properly tracked on github >>> >>> - https://github.com/pharo-project/pharo-core >> >> Nice! How do you track the changes? From Jenkins as a build step? >> >> Squeak doesn't do this yet, mainly because I've not got around to >> doing it. Because we don't use slices (maybe we should...) I'd >> pondered using a webhook off the squeaksource installation. > > It uses the FileSystem-ST that maps packages/classes/methods to an internal > FileSystem which can be easily written to disk: > > Gofer new > smalltalkhubUser: 'dh83' project: 'FileSystemST'; > package: 'ConfigurationOfFileSystemST'; > load. > > (Smalltalk at: #ConfigurationOfFileSystemST) loadDevelopment. > > FileSystem st root copyAllTo: 'pharo-core' asFileReference. OK, so you could do have a job that did something like * take base image * check out pharo-core * update it * save updated image * run that script to change pharo-core * commit and push * run tests (Maybe with a slightly different ordering in the steps.) You don't even need to make Jenkins do anything that way! (You just have to store the GitHub API tokens somewhere, maybe in an environment variable.) frank

May 18, 2013

Re: [Pharo-dev] 3.0 git tracker

by Frank Shearar

On 18 May 2013 09:53, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 18 May 2013 01:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> Pharo 3.0 is now properly tracked on github >> >> - https://github.com/pharo-project/pharo-core > > Nice! How do you track the changes? From Jenkins as a build step? What fileout format are you using? It looks like a custom job. (It's not chunk format or Filetree or gst style.) Although I'm not necessarily complaining here, since I have every intention of developing yet another fileout format. It turns out that Monticello can easily paper over the details of your fileout format - I have a (currently stalled because of unrelated issues) project that can load both fileout and Filetree formatted code from a GitHub repository, and from the perspective of the user, it's just Monticello. One request though - make a means of identifying the format please? At the moment FileTree puts a .filetree file in the repo, for instance. Perhaps if there are enough different filesystem formats we'll need to gather round and settle on a common identifier (.fileout-format, containing a symbol describing the format, or something), but at least today having a marker file means that a loader can easily figure out how to load the code. frank frank

May 18, 2013

Re: [Pharo-dev] 3.0 git tracker

by Camillo Bruni

On 2013-05-18, at 10:53, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 18 May 2013 01:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> Pharo 3.0 is now properly tracked on github >> >> - https://github.com/pharo-project/pharo-core > > Nice! How do you track the changes? From Jenkins as a build step? > > Squeak doesn't do this yet, mainly because I've not got around to > doing it. Because we don't use slices (maybe we should...) I'd > pondered using a webhook off the squeaksource installation. It uses the FileSystem-ST that maps packages/classes/methods to an internal FileSystem which can be easily written to disk: Gofer new smalltalkhubUser: 'dh83' project: 'FileSystemST'; package: 'ConfigurationOfFileSystemST'; load. (Smalltalk at: #ConfigurationOfFileSystemST) loadDevelopment. FileSystem st root copyAllTo: 'pharo-core' asFileReference.

May 18, 2013

Re: [Pharo-dev] 3.0 git tracker

by Frank Shearar

On 18 May 2013 01:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Pharo 3.0 is now properly tracked on github > > - https://github.com/pharo-project/pharo-core Nice! How do you track the changes? From Jenkins as a build step? Squeak doesn't do this yet, mainly because I've not got around to doing it. Because we don't use slices (maybe we should...) I'd pondered using a webhook off the squeaksource installation. frank

May 18, 2013

Re: [Pharo-dev] TxTextLayout

by plantec

Hi all, Yes, TxText is cool. I've still one important feature to implement for synectique then I will try to help. Rubric has the scrolling stuffs (scrolling text, rulers for line numbers, code size feedback, editing mode and soon, user defined selection). I will check if it can/needs to be ported for TxText. Cheers Alain On 17 mai 2013, at 08:47, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Denis > > I think that alain will start to look at TextModel too because we do not want to have rubric competing with it and > WE WANT ATHENS IN PHARO BEFORE the end of June. > Igor when you are back from holidays we will push athens into Pharo and start hakcing like mad :) > > Stef > > > On May 16, 2013, at 10:32 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> >> >> On 2013-05-16, at 13:04, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > Hello. >> > >> > 2013/5/16 Camillo Bruni <camillobruni(a)gmail.com> >> > >> >> I have a question concerning the new TxText layout. >> >> How hard is it support inline non-text nodes (aka inline morphs) in a text >> >> layout? >> >> >> > >> > Do you mean supporting "TxMorphSpan" objects from text model at text layout >> > level? >> > I think it is is not hard. Main issue here is supporting such kind of spans >> > at text model level. But I think it is not difficult too, >> > I should look at code to answer in detail (can't do it now). >> > >> > >> >> >> >> My dream is still to be able to drag and drop an "instance" from an >> >> inspector to a workspace and do some operations on it using standard >> >> smalltalk. >> > >> > >> > +1 >> > And I want drag and drop objects between inspectors and between workspaces. >> > >> > >> >> The only difference here would be instead of using a variable or >> >> expression to get an instance of something I would have a textual/visual >> >> node directly representing an instance! >> >> >> > >> > I'm not understand it. >> > By dropping some object to workspace It can create named variable and then >> > you can use it for scripting inside workspace. >> > But what you suggest here? Can you explan deeply? >> >> >> Indeed I am not very clear (as usual :). >> a) I want to have a morph representing an object >> b) I want to embed these morphs into text >> c) I want to interact with these morphs and the text >> >> Let's say [Set] is the morph representing a set and I have the following >> source code with this morph inside: >> >> [Set] includes: #a >> >> Then this would be equivalent to the following: >> >> Smalltalk at: #MySetInstance put Set new. >> >> MySetInstance includes: #a >> >> However [Set] is not just text but a real morph I can drag around, right click >> and get a decent, instance specific menu on... and so forth :) >> >> is that more clear? >> >> Ok. Now I understand what you want. >> >> I look at code. >> As I sad before. TxMorphSpan requires some changes in text model code and layout code. >> Now TxLayout is collection of TxLayoutLine's where TxLayoutLine is collection of TxLayoutSpan's. And now TxLayoutSpan is interval of TxCharacterSpan. So TxLayoutSpan know that it is layout of characters. It has font. >> One of the options to support TxMorphSpan layout is to introduce TxLayoutMorphSpan and implement all required protocol. To hook up this object during layout building you should implement something like: >> >> TxMorphSpan>>layoutContentsBy: aLayoutBuilder >> aLayoutBuilder currentSpan: (TxLayoutMorphSpan on: self) >> aLayoutBuilder completeSpan >> >> You see it is quite simple. >> >> Now I almost finich edit decorators stuff. (I have TxNoneEditDecorator, TxMaskEditDecorator, TxInsertModeEditDecorator, TxSmartCharsEditDecorator). And next my task will validation/filtering of input. I think it will require text model changes, so I will think about morph span too. >> And of couse if you again join to TxText development it will be perfect! You and Igor started this project. >> >> Best regards, >> Denis >> . >> >

May 18, 2013

Re: [Pharo-dev] Small Methods dont need comments , true or myth ?

by stephane ducasse

+1 > You are right that comments should explain the "why" and not the > "what". But not every single tiny little method needs to explain the > "why" of its existence. Do you think hundreds and hundreds of > #initialize methods need to explain themselves with a comment? I > don't. > >> Also a big issue I have with smalltalk in general. All this spaggeti mess I >> see unfold before my eyes in every library I see. >> One method calling another method which calls (excuse me, I should have said >> "sends a message") another and before >> you know you forget where you started and where is the end. Its the >> definition of Code Labyrinth. All this hectic browsing >> around could have been avoided so easily with a single comment. > > Your frustration about use of the Composed Method pattern is due to a > tool shortage, not a shortage of comments. Above, you're talking > about getting "lost" as you trace through senders and implementors. > When each sender/implementor either opens up a whole pane or, in some > cases, a whole new window, then yes, it's very easy to get "lost" and > forget where what you were doing due to following side-tracks. > > That's why I use Squeak's MessageTrace, it handles this better than > anything else in any Smalltalk. It is a "lightweight" way, in terms > of gestures and UI elements, to trace through code without getting > lost. I wish Pharo would consider implementing a tool like this. Can you explain it? This is the screenshot? The top line the sender for ensureSecondaryLinkConfigured then see its senders? Its self sends? Because I want (and I was thinking about that too for long time) something like that. > >> I would like to note here that I am also a big fan of small methods and that >> my question is not related to whether methods >> should be kept small and readable but whether comments are really needed for >> those methods. >

May 18, 2013

Re: [Pharo-dev] Stop saving the image at the end of an 'eval' script!

by stephane ducasse

can you update zeroConf chapter ? On May 17, 2013, at 6:05 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > If you have scripts you call with the command line argument 'eval' like this: > > ./pharo eval '1+2. Smalltalk snapshot: true andQuit: true' > > you will get into problems in Pharo 2.0 (e.g., a debugger with 'stdout > is closed' message). Pharo 3.0 does not have this problem. The correct > way to do that in Pharo 2.0 is: > > ./pharo eval --save '1+2' > > which is non-arguably much cleaner :-) > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

May 18, 2013

Re: [Pharo-dev] 3.0 git tracker

by Sven Van Caekenberghe

Cool. On 18 May 2013, at 02:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Pharo 3.0 is now properly tracked on github > > - https://github.com/pharo-project/pharo-core > - the update messages are properly shown > - html output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… > - diff output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… > - patch output: https://github.com/pharo-project/pharo-core/commit/cc3a428b19e2696e0540c4cc… Thanks for all this work. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 18, 2013