August 2014 - Pharo-dev - lists.pharo.org

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

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

by Tudor Girba

Excellent! :) Doru On Tue, Aug 12, 2014 at 10:25 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > "Sure. And?" > > And I love Pharo and so far , I am enjoying making tools for it :) > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 12, 2014

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

by kilon alios

"Sure. And?" And I love Pharo and so far , I am enjoying making tools for it :)

Aug. 12, 2014

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

by Max Leske

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> >> 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. 12, 2014

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

by stepharo

HI Ben This is really cool that you spend time on it! Thanks thanks thanks! Really thanks! if you need a circularList I'm coding one for the systemLogger. Just ask. (I'm about to change the API of the new linked list I wrote (I never like the Link and ValueLink that we have in the system) but Link for a linkedList is as good as Cell (if I do not like Link :)) so I'm about to stop thinking that I prefer Cell and I will make sure that both classes use the same vocabulary as our ancient linkedList. :) May be I'm becoming wise after all :) Stef

Aug. 12, 2014