- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Article] Elegant Pharo Code

by Sven Van Caekenberghe

Hi Sergi, On 13 Jul 2014, at 15:05, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: > It may have been mentioned already, but number 7 is wrong, is states: > > "7. Sum of the first 64 primes" > > when it actually is: > > "7. Sum of the primes not larger than 64" > > > Cheers, > Sergi I fixed that, thank you ! Sven > 2014-07-12 17:02 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 08 Jul 2014, at 21:53, kilon alios <kilon.alios(a)gmail.com> wrote: > > > Ruby and Pearl look very ugly to me. > > > > Programming languages are primarily personal preference. > > > > Pharo advantages to me at least are far more than live image, its live coding which by the way is different from live image, the IDE tools, the factor that is all Pharo objects even when you do assembly coding inside Pharo , the libraries of course and last but not least the community. > > > > I could name also thousands more advantages that I have found in the implementation that I really like as well others I don't. Devil , as they say, is in the details. Details are everything , generalisations have little meaning. > > > > Lovely article Sven , keep them coming. I think Pharo would definitely benefit from a cookbook working as a database where pharo coders can use to find example code the easy way. > > Thanks, Kilon. > > > But even articles like this can help a lot, I just wish that there was a Pharo wiki to keep these links and see them buried in Pharo news. > > Yes, I think we need more/better places to link everything together. A curated reading list maybe. > > > PS: Sven I am making my own Pharo book called Pharo Universe where I want to put things that are not part of PBE or PFTE which can be find here https://github.com/kilon/Pharo-Universe and here https://ci.inria.fr/pharo-contribution/job/PharoUniverse/ . May I have permission to use your articles as chapters for my book ? I will fully credit you and link back to your blog posts of course :) > > I know you are doing a lot of effort with respect to documentation and that is really great and important. I am not sure that copying articles that were not meant to be part of a book or larger whole is a good solution, for either party, it will give too much repetition and not a lot of coherence. > > > On Tue, Jul 8, 2014 at 10:33 PM, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > > Very nice, except all this could be done in Ruby, also elegantly. > > The Smalltalk advantage is the live image, and that's where the focus > > should be. > > > > > > >

Aug. 13, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by Tim Mackinnon

Thanks Esteban, thatâs definitely (minor point: you didnât use the same text I gave you below, so there are some grammatical errors on the site). If you want to keep control of how things are published - maybe it makes sense, and is much easier to set the rule: âGive me a complete page with changes in XXXX formatâ (you tell me what XXX is - markdown?). And then we can send you full pages you can paste in (and diff?) For now - can you also change the first paragraph, I think it makes more sense to say that Pharo.org is the main place for information, and so its much better to write: #How to propose a bug fix or enhancement First check if your change has already been entered into [Fogbugz](https://pharo.fogbugz.com/), and consider watching the [overview video](https://www.youtube.com/watch?v=iFomI-7h4qQ) of the steps documented below. Can you also change the Pre-reqs section to fix some minor typos (and match the formatting of the text further down) ##Prerequisites In order to propose a bug fix or enhancement for Pharo you need: - An account for the [Fogbugz Pharo Issue Tracker]( https://pharo.fogbugz.com) - An account on [SmalltalkHub](http://smalltalkhub.com) with commit rights to the [Pharo Inbox]( http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) _Note, in the recent version of SmalltalkHub this is a public repository. If you encounter problems you can ask for commit rights on the [Pharo Developers mailinglist(http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.o… > Tim On 12 Aug 2014, at 12:30, EstebanLM [via Smalltalk] <ml-node+s1294792n4772981h91(a)n4.nabble.com> wrote: > > On 11 Aug 2014, at 18:28, Tim Mackinnon <[hidden email]> wrote: > >> Bump? The text on http://pharo.org/contribute-propose-fix is still wrong - can someone include the text I fixed up below? > > fixed > > Esteban > >> >> Also - do we want to make pharo.org the primary place for docs (and hence change the first paragraph to: >> >> #How to propose a bug fix or enhancement >> First check if your change has already been entered into Fogbugz, and consider watching the [overview video](https://www.youtube.com/watch?v=iFomI-7h4qQ) of the steps documented below. >> >> If we want to move away from the Fogbugz wiki, I will also simplify some of the text and point it back to pharo.org. >> >> Tim >> >> On 8 Aug 2014, at 08:40, Tim Mackinnon <[hidden email]> wrote: >> >>> Ok - Iâve fixed my faux-pas and propose the following text (a slight rework of what is published now). Taking a hint from Martin there is a notehub link here (http://notehub.org/2014/8/8/how-to-propose-a-bug-fix-or-enhancement) - although Iâve noticed notehub handles sub-bullets a bit strangely. We might also want to do another slight change if we agree that Fogbugz should be secondary content (if so - adjust the first paragraph to something like: Check if your change has already been entered into Fogbugz, and consider watching the overview video of the steps documented below.) >>> >>> ââ >> >> >>> #How to propose a bug fix or enhancement >>> First check you meet the submission requirements and are familiar with the more detailed [contribution steps](https://pharo.fogbugz.com/default.asp?W68) (watch the [tutorial video](https://pharo.fogbugz.com/default.asp?pg=pgDownload&pgType=pgWikiAtt…, it's great!) >>> >>> ##Prerequisites >>> In order to propose a bug fix or enhancement for Pharo you need: >>> >>> - An account for the [Fogbugz Pharo Issue Tracker]( https://pharo.fogbugz.com) >>> - An account on [SmalltalkHub](http://smalltalkhub.com) with rights to the [Pharo Inbox]( http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) >>> _Note, in the recent version of SmalltalkHub this is a public repository. If you encounter problems you can ask for commit rights on the [Pharo Developers mailinglist(http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.o… >>> >>> ##Procedure >>> To commit a change, you will follow these steps: >>> >>> - Take the latest [stable or development system](http://pharo.org/download), ideally using the latest virtual machine for your OS >>> - Ensure you have created [details of the issue in the Fogbugz issue tracker] (https://pharo.fogbugz.com) >>> - Create a code fix (ideally with a [unit test](http://pharo.gforge.inria.fr/PBE1/PBE1ch8.html) exercising the working code) >>> - Create a Monticello Slice (group of packages) for your changes: >>> - Open the Monticello Browser >>> - Open the Slice Maker by clicking the "Slice" button >>> - In Slice Maker enter the Fogbugz issue number and "grab" the issue summary >>> - Select all dirty packages affected by your fix >>> - Verify your changes (click the Changes button) >>> - Select the Pharo40 repository >>> - Select your Slice >>> - Press changes in the Monticello Browser and verify that your changes are correct >>> - Publish the Slice to the inbox: >>> - Select the whole Slice (not it's individual packages). >>> - Select the SmalltalkHub Pharo Inbox repository. >>> - Commit the Slice. >>> - Verify that your fix loads: >>> - Take a fresh image and load the Slice you just published >>> - Update the bug entry to mention that you submitted a Slice in the inbox >>> - Now sit back and feel good! You've helped influence a brighter future... >>> >>> You can also contribute to Pharo by proposing enhancements on the mailing list and/or by submitting a Fogbugz issue. Note that all code submitted to the [Pharo repositories](http://smalltalkhub.com/#!/~Pharo) is licensed under the [MIT license]http://opensource.org/licenses/MIT) Do not forget to sign the [license agreement](http://files.pharo.org/media/PharoSoftwareDistributionAgreement.…. >>> >>> >>> On 8 Aug 2014, at 07:16, Tim Mackinnon <[hidden email]> wrote: >>> >>>> Stef - I've confused you with my suggestion. Where I wrote "use link" after the text in [] - I meant put that hyperlink for the [text]. >>>> >>>> Sorry, I was writing my reply in a text editor and was doing a sort of pseudo markdown syntax. >>>> >>>> Looking at where this is going - maybe we should instead make the Pharo.org site the main source of info and not Fogbugz? We have a duplication problem - and when things change we end up with conflicting instructions as we forget to update the other copies. Essentially we need to refactor the docs. >>>> >>>> Is Pharo.org easily editable by others (is this the Pillar bit?). If it was then I would say let's edit the Fogbugz pages - simplify them and point them back to the more detailed Pharo.org pages. >>>> >>>> For now, I will find a laptop and send some cleaned up text. >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>> On 7 Aug 2014, at 10:45 pm, "stepharo [via Smalltalk]" <<a href="x-msg://28/user/SendEmail.jtp?type=node&node=4772414&i=0" target="_top" rel="nofollow" link="external">[hidden email]> wrote: >>>> >>>>> in fact I just did a merge with the version of Tim and it is looking great. >>>>> On 7/8/14 22:32, stepharo wrote: >>>>> >>>>> > Thanks martin I will have a look tomorrow. >>>>> > >>>>> > Stef >>>>> > >>>>> > On 7/8/14 22:11, MartinW wrote: >>>>> >> Could you extend http://pharo.org/contribute-propose-fix a bit? And >>>>> >> add a >>>>> >> screenshot of Slice Maker (I attach one). The following text would have >>>>> >> helped me (I paste the markdown. I also posted it on NoteHub for a >>>>> >> better >>>>> >> reading experience >>>>> >> http://www.notehub.org/2014/8/7/how-to-propose-a-bug-fix) >>>>> >> >>>>> >> #How to propose a bug fix: >>>>> >> ##Prerequesites: >>>>> >> In order to propose a bug fix or enhancement for Pharo you need: >>>>> >> >>>>> >> - an account at the [Pharo Issue Tracker on >>>>> >> Fogbugz](https://pharo.fogbugz.com), >>>>> >> - a [SmalltalkHub](http://smalltalkhub.com) account and >>>>> >> - the commit right for the [Pharo Inbox on >>>>> >> SmalltalkHub](http://smalltalkhub.com/#!/~Pharo/Pharo40Inbox) (Ask on >>>>> >> the >>>>> >> [Pharo Developers >>>>> >> mailinglist](http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.… >>>>> >> >>>>> >> for the commit right). >>>>> >> >>>>> >> ##Procedure: >>>>> >> - Take the latest stable or latest development system, ideally using the >>>>> >> latest virtual machine. >>>>> >> - Do a fix for a given bug, or a new bug you entered to the issue >>>>> >> tracker. >>>>> >> - Create a slice (group of packages): >>>>> >> - Open the Monticello Browser. >>>>> >> - Open the Slice Maker by clicking the **+Slice** button. >>>>> >> - In Slice Maker enter the Fogbugz issue number and **grab** the >>>>> >> issue >>>>> >> summary. >>>>> >> - Select all dirty packages affected by your bug fix. >>>>> >> - Publish the slice to the inbox: >>>>> >> - Select the whole slice (not it's individual packages). >>>>> >> - Select the SmalltalkHub Pharo Inbox repository. >>>>> >> - Commit your slice. >>>>> >> - Verify that your fix loads: take a fresh image and load the slice you >>>>> >> published. >>>>> >> - Update the bug entry to mention that you submitted a slice in the >>>>> >> inbox. >>>>> >> >>>>> >> You can also contribute to Pharo by proposing enhancements following the >>>>> >> same process. Note that all code submitted to the Pharo repositories is >>>>> >> licensed under the MIT license. Do not forget to sign the license >>>>> >> agreement. >>>>> >> >>>>> >> <http://forum.world.st/file/n4772388/SliceMaker.png> >>>>> >> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> View this message in context: >>>>> >> http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-righ… >>>>> >> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>> >> Nabble.com. >>>>> >> >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>>> If you reply to this email, your message will be added to the discussion below: >>>>> http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-righ… >>>>> To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. >>>>> NAML >>>> >>>> View this message in context: Re: About your contributions: Improve Pharo right now, right there. >>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >> > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-righ… > To unsubscribe from About your contributions: Improve Pharo right now, right there., click here. > NAML -- View this message in context: http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-righ… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 13, 2014

Re: [Pharo-dev] Faster ThreadSafeTranscript Re: [pharo-project/pharo-core] 06d05b: 40165

by Guillermo Polito

Well, I have no idea why that line is there :). It's old (so I do not remember), a tweak (read Â´hackÂ´) I probably did to make the bootstrap work at the time, and I don't think it's correct that line is there, so maybe we should remove it? :) On Tue, Aug 12, 2014 at 10:03 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 12.08.2014, at 14:27, Ben Coman <btc(a)openInWorld.com> wrote: > > GitHub wrote: > > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 06d05bd822deee4a79736d9f99d4a666ca1637eb > https://github.com/pharo-project/pharo-core/commit/06d05bd822deee4a79736d9f… > Author: Jenkins Build Server <board(a)pharo-project.org> <board(a)pharo-project.org> > Date: 2014-08-11 (Mon, 11 Aug 2014) > > > 13806 Remove ThreadSafeTranscriptPluggableTextMorph > https://pharo.fogbugz.com/f/cases/13806 > > > > For anyone concerned about the performance of writing to Transcript from > higher priority threads, just reporting that altering ThreadSafeTranscript > to be safe for Morphic without ThreadSafeTranscriptPluggableTextMorph had a > side effect of enhancing performance by 25x. With two runs of the > following script... > > Smalltalk garbageCollect. > Transcript open. "close after each run" > [ Transcript crShow: ( > [ > | string | > string := '-'. > 1 to: 2000 do: > [ :n | > string := string , '-', n printString. > Transcript show: string. > ]. > (Delay forMilliseconds: 10) wait. > ]) timeToRun. > ] forkAt: 41. > > > > Build 40162 reports timeToRun of 0:00:00:02.483 & 0:00:00:02.451 > Build 40165 reports timeToRun of 0:00:00:00.037 & 0:00:00:00.099 > > > Now I had meant to ask... I notice that FLFuelCommandLineHandler installs > ThreadSafeTranscript, so I wonder it is affected by this change. Can some > Fuel experts comment? > > > Hi Ben > > I tried to figure this out with Mariano. Apparently the Transcript parts > come from an improvement that was suggested by Pavel Krivanek (see this > issue: http://code.google.com/p/pharo/issues/detail?id=6428) The code > presumably was tailored to the needs that Hazel (today called Seed > http://smalltalkhub.com/#!/~Guille/Seed) had. We couldnât find any other > reason why we would do *anything* Transcript related, especially since the > command line handlers print to stdout anyway. > > Mariano suggested I CC Ben and Guille, so Iâm doing that. Maybe one of the > two can shed some light on that method. From my point of view I donât see > why we should keep that part of the code. > > Cheers, > Max > > > > Also I am looking for some advice for a minor downside I just noticed. > The whole script above can complete between steps, so the entire output > ends up in the PluggableTextMorph its size without being culled, which > causes making a selection become really slow. Normally the excess text > shown by Transcript is culled in half [1] by > PluggableTextMorph>>appendEntry each time #changed: is called. > > PluggabletextMorph>>appendEntry > "Append the text in the model's writeStream to the editable text. " > textMorph asText size > model characterLimit ifTrue: "<---[0]" > ["Knock off first half of text" > self selectInvisiblyFrom: 1 to: textMorph asText size // 2. > "<---[1]" > self replaceSelectionWith: Text new]. > self selectInvisiblyFrom: textMorph asText size + 1 to: textMorph > asText size. > self replaceSelectionWith: model contents asText. "<----[2]" > self selectInvisiblyFrom: textMorph asText size + 1 to: textMorph > asText size > > That works fine when #appendEntry is being called with lots of small > changes, but for a single large change the entire change ends up in > PluggableTextMorph via [2]. In this case > model characterLimit "--> 20,000" [0] > model contents size "--> 5,671,343" [2] > where model == Transcript. > > So what is the behaviour you'd like to when too much is sent to Transcript? > a. Show all content however briefly. > b. Only the last 20,000 characters are put into the PluggableTextMorph, > and the earlier data thrown away. > > I see a few ways to deal with this: > 1. Limit the stream inside Transcript to a maximum 20,000 characters by > basing it on some circular buffer. > 2. Have "Transcript conents" return only the last 20,000 characters of its > stream. > 3. Limit to text sent to #replaceSelectionWith: [2] to 20,000 characters. > > Thoughts anyone? > > cheers -ben > > >

Aug. 13, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by Roberto Minelli

Thanks a lot Kilon. Indeed using the arrow keys to browse methods is the only thing that it is really noticeable due to the high amount of API calls that Pharo triggers to do so (and that DFlow profiles). On Aug 13, 2014, at 10:23 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > At first I thought maybe it was a strange interaction with Phratch because it has a very "heavy" Morph GUI but I tried DFlow on a clean Pharo 3 latest image and the lag is quite noticeable when I use the arrow keys to browse quickly through messages in a System Browsers. But its not a game stopper so I can tolerate it. > > > On Wed, Aug 13, 2014 at 9:58 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi Kilon, > > I am using DFlow everyday and never experienced an noticeable slowdown. > I will do my best to make it fast! > > Cheers, > R > > > On Aug 12, 2014, at 3:48 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > > I have enabled your DFlow tool, but it looks like it severely slows down Pharo. Browsing through methods was instantaneous but with DFlow I see at least a one second lag which make its use quite an obstacle to my workflow. > > > > I am on macos 10.9 maverics with a 2011 macbook air. > > > > > > On Tue, Aug 12, 2014 at 4:31 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > Hi, > > > > I agree with you Kilon, thanks for your observation (and future help). > > > > My interaction profiler is only a means to the end. As Doru is saying, my goal is to use the data captured by > > DFlow to understand how developers work and what they need in their context. > > > > In the short term I want to analyze how developers work, but then I will do my best to bridge the gap between > > what our IDEs offer and what we need. > > > > P.s. Thanks Doru for your support! > > > > Cheers, > > Roby > > > > On Aug 12, 2014, at 2:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > > Hi Kilon, > > > > > > Excellent observation! > > > > > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is simple: make it dead cheap for the developer to mold the IDE to his/her contextual needs. > > > > > > Until now, we have announced an inspector and a debugger that do just that. The inspector makes it possible to mold the tool for every little object if you desire. For example, I alone have built literally hundreds of extensions for various objects. Actually, the inspector goes as far as to allow you to mold the flow to the context in which you are. The debugger lets you define custom debuggers that you can switch to while debugging. All these extensions are incredibly small (an object inspector extension has an average of 8 lines, and the debuggers we implemented consist of a couple of hundred loc), they are independent of each other, and they are put together through a small frame. Add to that the potential of using multiple rendering engines and we get a brand new philosophy that I believe holds the potential to change software development significantly. > > > > > > This is not a far goal. It's a reality now. At ESUG, we will show how these tools work now in practice. > > > > > > What Roberto is doing is complementary to our efforts. Data mining will certainly play a significant role in this picture, precisely when we will start to have thousands of these little contextual tools. At this time, DFlow is experimental, but eventually a tool like this should become part of the IDE as we need to understand how developers work in their context and what they need in their context. That is why his effort should be supported by our community. Please install it and give feedback. > > > > > > Cheers, > > > Doru > > > > > > > > > > > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > > I think the future are tools tailor made for specific kind of tasks . The age of IDEs and Languages has come to an end. Neither programming languages and IDEs can maintain the complexity of modern software. They are too generic.I think that what we need is a UNIX system but with GUIs , a collection of tools that can talk to each other but at the same time have an extremely limited scope as tools. Smalltalk definitely moves towards that direction but even Smalltalk is far from that goal. > > > > > > I see that paradigm a lot in 3d art, it raises the amount of knowledge required because you end up with learning hundreds of tools contained in a single application but if you want professional results and you are dead serious about efficiency and productivity then its the way to go. > > > > > > I will install DFlow and help you in your saga, but bare in mind that DFlow will tell you what I use and I how , but it wont answer you the most important question "what I want to use and how I want to use it" . > > > > > > > > > On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > > Hi guys, > > > > > > I uploaded a web page to explain Self-Adaptive IDEs, the vision I will develop for my Ph.D > > > http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. > > > > > > Please take a minute to look at it and tell me your opinion! > > > > > > At the moment we are conducting an experiment with my interaction profiler (DFlow). It would be > > > great if you could participate! This will cost you little effort but help me to gather an understanding > > > of development practices and interactions. This is the ground for improving our Pharo IDE! > > > > > > Cheers and thanks in advance, > > > Roberto > > > > > > > > > > > > > > > > > > > > > -- > > > www.tudorgirba.com > > > > > > "Every thing has its own flow" > > > > > > > > >

Aug. 13, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by kilon alios

At first I thought maybe it was a strange interaction with Phratch because it has a very "heavy" Morph GUI but I tried DFlow on a clean Pharo 3 latest image and the lag is quite noticeable when I use the arrow keys to browse quickly through messages in a System Browsers. But its not a game stopper so I can tolerate it. On Wed, Aug 13, 2014 at 9:58 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi Kilon, > > I am using DFlow everyday and never experienced an noticeable slowdown. > I will do my best to make it fast! > > Cheers, > R > > > On Aug 12, 2014, at 3:48 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > > I have enabled your DFlow tool, but it looks like it severely slows down > Pharo. Browsing through methods was instantaneous but with DFlow I see at > least a one second lag which make its use quite an obstacle to my workflow. > > > > I am on macos 10.9 maverics with a 2011 macbook air. > > > > > > On Tue, Aug 12, 2014 at 4:31 PM, Roberto Minelli <roberto.minelli(a)usi.ch> > wrote: > > Hi, > > > > I agree with you Kilon, thanks for your observation (and future help). > > > > My interaction profiler is only a means to the end. As Doru is saying, > my goal is to use the data captured by > > DFlow to understand how developers work and what they need in their > context. > > > > In the short term I want to analyze how developers work, but then I will > do my best to bridge the gap between > > what our IDEs offer and what we need. > > > > P.s. Thanks Doru for your support! > > > > Cheers, > > Roby > > > > On Aug 12, 2014, at 2:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > > Hi Kilon, > > > > > > Excellent observation! > > > > > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea > is simple: make it dead cheap for the developer to mold the IDE to his/her > contextual needs. > > > > > > Until now, we have announced an inspector and a debugger that do just > that. The inspector makes it possible to mold the tool for every little > object if you desire. For example, I alone have built literally hundreds of > extensions for various objects. Actually, the inspector goes as far as to > allow you to mold the flow to the context in which you are. The debugger > lets you define custom debuggers that you can switch to while debugging. > All these extensions are incredibly small (an object inspector extension > has an average of 8 lines, and the debuggers we implemented consist of a > couple of hundred loc), they are independent of each other, and they are > put together through a small frame. Add to that the potential of using > multiple rendering engines and we get a brand new philosophy that I believe > holds the potential to change software development significantly. > > > > > > This is not a far goal. It's a reality now. At ESUG, we will show how > these tools work now in practice. > > > > > > What Roberto is doing is complementary to our efforts. Data mining > will certainly play a significant role in this picture, precisely when we > will start to have thousands of these little contextual tools. At this > time, DFlow is experimental, but eventually a tool like this should become > part of the IDE as we need to understand how developers work in their > context and what they need in their context. That is why his effort should > be supported by our community. Please install it and give feedback. > > > > > > Cheers, > > > Doru > > > > > > > > > > > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> > wrote: > > > I think the future are tools tailor made for specific kind of tasks . > The age of IDEs and Languages has come to an end. Neither programming > languages and IDEs can maintain the complexity of modern software. They are > too generic.I think that what we need is a UNIX system but with GUIs , a > collection of tools that can talk to each other but at the same time have > an extremely limited scope as tools. Smalltalk definitely moves towards > that direction but even Smalltalk is far from that goal. > > > > > > I see that paradigm a lot in 3d art, it raises the amount of knowledge > required because you end up with learning hundreds of tools contained in a > single application but if you want professional results and you are dead > serious about efficiency and productivity then its the way to go. > > > > > > I will install DFlow and help you in your saga, but bare in mind that > DFlow will tell you what I use and I how , but it wont answer you the most > important question "what I want to use and how I want to use it" . > > > > > > > > > On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli < > roberto.minelli(a)usi.ch> wrote: > > > Hi guys, > > > > > > I uploaded a web page to explain Self-Adaptive IDEs, the vision I will > develop for my Ph.D > > > http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. > > > > > > Please take a minute to look at it and tell me your opinion! > > > > > > At the moment we are conducting an experiment with my interaction > profiler (DFlow). It would be > > > great if you could participate! This will cost you little effort but > help me to gather an understanding > > > of development practices and interactions. This is the ground for > improving our Pharo IDE! > > > > > > Cheers and thanks in advance, > > > Roberto > > > > > > > > > > > > > > > > > > > > > -- > > > www.tudorgirba.com > > > > > > "Every thing has its own flow" > > > > > > > > >

Aug. 13, 2014

Re: [Pharo-dev] Our vision: Self-Adaptive IDEs

by Roberto Minelli

Hi Kilon, I am using DFlow everyday and never experienced an noticeable slowdown. I will do my best to make it fast! Cheers, R On Aug 12, 2014, at 3:48 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > I have enabled your DFlow tool, but it looks like it severely slows down Pharo. Browsing through methods was instantaneous but with DFlow I see at least a one second lag which make its use quite an obstacle to my workflow. > > I am on macos 10.9 maverics with a 2011 macbook air. > > > On Tue, Aug 12, 2014 at 4:31 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Hi, > > I agree with you Kilon, thanks for your observation (and future help). > > My interaction profiler is only a means to the end. As Doru is saying, my goal is to use the data captured by > DFlow to understand how developers work and what they need in their context. > > In the short term I want to analyze how developers work, but then I will do my best to bridge the gap between > what our IDEs offer and what we need. > > P.s. Thanks Doru for your support! > > Cheers, > Roby > > On Aug 12, 2014, at 2:57 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi Kilon, > > > > Excellent observation! > > > > The Glamorous Toolkit implements the idea of a Moldable IDE. The idea is simple: make it dead cheap for the developer to mold the IDE to his/her contextual needs. > > > > Until now, we have announced an inspector and a debugger that do just that. The inspector makes it possible to mold the tool for every little object if you desire. For example, I alone have built literally hundreds of extensions for various objects. Actually, the inspector goes as far as to allow you to mold the flow to the context in which you are. The debugger lets you define custom debuggers that you can switch to while debugging. All these extensions are incredibly small (an object inspector extension has an average of 8 lines, and the debuggers we implemented consist of a couple of hundred loc), they are independent of each other, and they are put together through a small frame. Add to that the potential of using multiple rendering engines and we get a brand new philosophy that I believe holds the potential to change software development significantly. > > > > This is not a far goal. It's a reality now. At ESUG, we will show how these tools work now in practice. > > > > What Roberto is doing is complementary to our efforts. Data mining will certainly play a significant role in this picture, precisely when we will start to have thousands of these little contextual tools. At this time, DFlow is experimental, but eventually a tool like this should become part of the IDE as we need to understand how developers work in their context and what they need in their context. That is why his effort should be supported by our community. Please install it and give feedback. > > > > Cheers, > > Doru > > > > > > > > > > On Tue, Aug 12, 2014 at 2:06 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > I think the future are tools tailor made for specific kind of tasks . The age of IDEs and Languages has come to an end. Neither programming languages and IDEs can maintain the complexity of modern software. They are too generic.I think that what we need is a UNIX system but with GUIs , a collection of tools that can talk to each other but at the same time have an extremely limited scope as tools. Smalltalk definitely moves towards that direction but even Smalltalk is far from that goal. > > > > I see that paradigm a lot in 3d art, it raises the amount of knowledge required because you end up with learning hundreds of tools contained in a single application but if you want professional results and you are dead serious about efficiency and productivity then its the way to go. > > > > I will install DFlow and help you in your saga, but bare in mind that DFlow will tell you what I use and I how , but it wont answer you the most important question "what I want to use and how I want to use it" . > > > > > > On Tue, Aug 12, 2014 at 10:30 AM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > > Hi guys, > > > > I uploaded a web page to explain Self-Adaptive IDEs, the vision I will develop for my Ph.D > > http://www.inf.usi.ch/phd/minelli/self-adaptive-ides/index.html. > > > > Please take a minute to look at it and tell me your opinion! > > > > At the moment we are conducting an experiment with my interaction profiler (DFlow). It would be > > great if you could participate! This will cost you little effort but help me to gather an understanding > > of development practices and interactions. This is the ground for improving our Pharo IDE! > > > > Cheers and thanks in advance, > > Roberto > > > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > >

Aug. 13, 2014

Re: [Pharo-dev] bitmaps in Athens

by Natalia Tymchuk

Thank you. Best regards, Natalia On Aug 13, 2014, at 12:03 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > TRBitmapShape only defines the paint to use, but not the shape. > athensCanvas setShape: (0@0 extent: self extent). > > or > > athensCanvas setShape: self path > IF TRBitmapShape defines the subclass responsiblility #computePath > > > > > > > 2014-08-12 22:42 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Natalia has a problem when using bitmaps with Roassal. I am not sure where the problems comes from. Resizing the window or the morph that contains a bitmap changes the size of the bitmap. I have illustrated this in this video: > > https://dl.dropboxusercontent.com/u/31543901/TMP/problemWithBitmapInAthens.… > > Is someone experiencing the same problem? I am not sure where to dig in. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Aug. 13, 2014

Re: [Pharo-dev] bitmaps in Athens

by Alexandre Bergel

Wow Nicolai! Impressive! It works perfectly!!! I owe you a beer :-) Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Aug 12, 2014, at 6:03 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > TRBitmapShape only defines the paint to use, but not the shape. > athensCanvas setShape: (0@0 extent: self extent). > > or > > athensCanvas setShape: self path > IF TRBitmapShape defines the subclass responsiblility #computePath > > > > > > > 2014-08-12 22:42 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Natalia has a problem when using bitmaps with Roassal. I am not sure where the problems comes from. Resizing the window or the morph that contains a bitmap changes the size of the bitmap. I have illustrated this in this video: > > https://dl.dropboxusercontent.com/u/31543901/TMP/problemWithBitmapInAthens.… > > Is someone experiencing the same problem? I am not sure where to dig in. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Aug. 12, 2014

Re: [Pharo-dev] bitmaps in Athens

by Nicolai Hess

TRBitmapShape only defines the paint to use, but not the shape. athensCanvas setShape: (0@0 extent: self extent). or athensCanvas setShape: self path IF TRBitmapShape defines the subclass responsiblility #computePath 2014-08-12 22:42 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Natalia has a problem when using bitmaps with Roassal. I am not sure where > the problems comes from. Resizing the window or the morph that contains a > bitmap changes the size of the bitmap. I have illustrated this in this > video: > > > https://dl.dropboxusercontent.com/u/31543901/TMP/problemWithBitmapInAthens.… > > Is someone experiencing the same problem? I am not sure where to dig in. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Aug. 12, 2014

bitmaps in Athens

by Alexandre Bergel

Hi! Natalia has a problem when using bitmaps with Roassal. I am not sure where the problems comes from. Resizing the window or the morph that contains a bitmap changes the size of the bitmap. I have illustrated this in this video: https://dl.dropboxusercontent.com/u/31543901/TMP/problemWithBitmapInAthens.… Is someone experiencing the same problem? I am not sure where to dig in. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 12, 2014