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

Re: [Pharo-dev] Create window group for Playground

by Torsten Bergmann

Hi Doru, >You are now talking about exactly one item out of 10. When was the last time you used the >Close menu entry from that menu? As I said in my mail - I'm more keen on getting the feature back than getting back this menu. >If we do not go through this process we will find out in 10 years that we have the same >solutions around us. I know it can be painful but the investment is worth it. Will "we be better" when we remove a windows menu because we usually use keyboard shortcuts to close windows? I doubt it. Where do you want to put the info what can be done with the window? Look at all the regular computer window based UI system: they still have such a menu. Will we really break with these expectations? For sure we could slim down and reduce it because we do not like it. But in regular OS systems these contain textual menu infosÂ what you can do and to my knowledge this is also used by accessibility tools like screen readers, ... Â >Well. It is hard to come with new things by doing exactly the same things as yesterday. Agree with that - but other window manager designers where not too bad in thinking about such issues. Â >So, that means that you do prefer the Playground after all :) Yes. Do do not misunderstand my posts. I enjoy these new tools - still I ask you questions like "why do I click on Workspace and get a Playground" or "why is grouping not possible anymore"? To me the first one is simply not intuitive and the other one a break in my flow. >That might be a solution, but what we have now is not such a solution. >Please give us time. Yes - maybe we must be more patient. I understand that sometimes one has to go 1 step backward to move 2 steps forward :) Bye T.

Jan. 30, 2015

Tools for automatic recognition of Design Patterns

by Nevena Milojkovic

Hi, Can anyone suggest me tool for automatic design patterns detection in Smalltalk? Cheers, Nevena Milojkovic ââââââââ Nevena Milojkovic Research assistant Software Composition Group Institute of Computer Science and Applied Mathematics University of Bern email: nevena(a)iam.unibe.ch office phone: +41 (0)31 511 7639 webpage: http://scg.unibe.ch/staff/Milojkovic

Jan. 30, 2015

Re: [Pharo-dev] Create window group for Playground

by Ben Coman

On Fri, Jan 30, 2015 at 11:06 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > On Fri, Jan 30, 2015 at 3:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> >Peter UhnÃ¡k >> >It's still a regular window, so it's possible, the only difference is >> missing button for it, which according to Tudor was removed purposefully. >> > >> > >> http://forum.world.st/GT-Playground-Inspect-window-menu-tp4782020p4782044.h… >> >> Looks like I missed this thread. Tudor comment is a little bit funny >> there: "by default in Morphic every window gets the generic menu that >> nobody really uses,". When he does not use it it does not mean that all >> other do not use it ;) >> > > You are now talking about exactly one item out of 10. When was the last > time you used the Close menu entry from that menu? > If we do not go through this process we will find out in 10 years that we > have the same solutions around us. I know it can be painful but the > investment is worth it. > > > I agree with that philosophy. Now btw, one menu item I do miss is "Make uncloseable". This make it easier/safer to clean up using "Windows > Delete all windows discarding edits" **. Perhaps that could become a pin icon next the to normal three min/max/close icons in the top left? **though the Plague Doctor might be interesting to try cheers -ben

Jan. 30, 2015

Re: [Pharo-dev] Create window group for Playground

by Tudor Girba

Hi, On Fri, Jan 30, 2015 at 3:06 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >Peter UhnÃ¡k > >It's still a regular window, so it's possible, the only difference is > missing button for it, which according to Tudor was removed purposefully. > > > > > http://forum.world.st/GT-Playground-Inspect-window-menu-tp4782020p4782044.h… > > Looks like I missed this thread. Tudor comment is a little bit funny > there: "by default in Morphic every window gets the generic menu that > nobody really uses,". When he does not use it it does not mean that all > other do not use it ;) > You are now talking about exactly one item out of 10. When was the last time you used the Close menu entry from that menu? If we do not go through this process we will find out in 10 years that we have the same solutions around us. I know it can be painful but the investment is worth it. I like when we make progress - but we should also take care not to > constantly break others flow. > Well. It is hard to come with new things by doing exactly the same things as yesterday. > I also currently circumvent the missing functionality the same way as > Kilon describes: by opening an old workspace first, > switching to grouping and dragging the playgrounds there. So, that means that you do prefer the Playground after all :) > Please can we have this grouping back somehow. I dont care about > the window menu itself but the grouping avoids the windows hell and we > should get this back. > In the long term I envision that I can drag windows (like playgrounds or > Nautilus) onto each other > and when I do this long enough they will group automagically. > That might be a solution, but what we have now is not such a solution. Please give us time. Doru -- www.tudorgirba.com "Every thing has its own flow"

Jan. 30, 2015

Re: [Pharo-dev] Create window group for Playground

by Atlas

Funny, I didn't know about that feature either. Thanks for the informative video, kilon. > The issue of many windows is a significant problem that deserves a closer > attention. Well, for starters, I am wondering why the World Window is limited to my screen size (or have I missed something?). I think it would make a better experience if the main window was infinite in size just like in the Self Environment <http://www.selflanguage.org/> . This way I could put windows, workspaces and other artifacts to locations that have specific meanings to me (spatial memory, very important), just like you would organize any working place. This would work great with a seemless zoom function. <http://forum.world.st/file/n4802751/cvp1yvcvjigd3fyi7.gif> In addition, it might be helpful to have multiple world windows and to be able to arrange them, just like in Xmonad <http://xmonad.org/> . Unfortuantely, I do not have the resources to implement that but I think that these changes would be very beneficial. For a start, it would be great to have a zoomable infinite workspace. -- View this message in context: http://forum.world.st/Create-window-group-for-Playground-tp4802517p4802751.… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 30, 2015

Re: [Pharo-dev] Plague Doctor

by kilon alios

Easier for you or me ? :D Unfortunately my free time is too limited to try everything that pops up to the mailing list to later find out that I can't get it to work because of limited/non existent documentation and me having no clue what the thing is doing or spend time on something that does not interest me. So its easier to just ignore it and move on. But since I am super interested to solutions that make managing windows more manageable (pun intended) I can't resist trying this out. On Fri, Jan 30, 2015 at 4:35 PM, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > Woop, didn't check for copyright when I did the poster. However, the > Plague Doctor monitors the usage of windows in the Pharo IDE and closes the > ones that are likely not to be used. It uses (optional) visual clues the > "importance" of a windows (heat scale from blue to red) and fades away not > used windows. > > It's easier if you give it a try! > > On 30 Jan 2015, at 12:57, kilon alios <kilon.alios(a)gmail.com> wrote: > > Bare in mind that using Copyrighted images without the permission of the > author makes you liable to be sued. > > So what is Plague Doctor ? The smalltalkhub description does not help at > all, what is that "window plague" ? > > On Fri, Jan 30, 2015 at 1:28 PM, stepharo <stepharo(a)free.fr> wrote: > >> :) >> >> Great picture! I love Plague Doctor >> freaking guy. >> >> Stef >> >> Le 30/1/15 11:29, Roberto Minelli a Ã©crit : >> >> To follow Stefâs advice of advertising our projects, here is the Plague >> Doctor! >> >> During development your Pharo IDE will quickly become overcrowded with >> unused windows. The Plague Doctor is a tool, inspired by Autumn Leaves, >> that helps you to mitigate this issue by closing the windows that you are >> less likely to use in the future. >> >> If you want to try our prototype, please install it with the following >> script or ask me for a quick demo (I am Lille for the PharoDays!). >> >> Gofer new >> smalltalkhubUser: 'RobertoMinelli' project: 'PlagueDoctor'; >> package: 'ConfigurationOfPlagueDoctor'; >> load. >> (Smalltalk at: #ConfigurationOfPlagueDoctor) loadDevelopment. >> >> <mime-attachment.png> >> >> http://smalltalkhub.com/#!/~RobertoMinelli/PlagueDoctor >> >> P.s. If you report a problem or a feature request, please file in an >> entry >> https://github.com/RobertoMinelli/PlagueDoctor/issues >> >> >> >

Jan. 30, 2015

Re: [Pharo-dev] Plague Doctor

by Roberto Minelli

Woop, didn't check for copyright when I did the poster. However, the Plague Doctor monitors the usage of windows in the Pharo IDE and closes the ones that are likely not to be used. It uses (optional) visual clues the "importance" of a windows (heat scale from blue to red) and fades away not used windows. It's easier if you give it a try! > On 30 Jan 2015, at 12:57, kilon alios <kilon.alios(a)gmail.com> wrote: > > Bare in mind that using Copyrighted images without the permission of the author makes you liable to be sued. > > So what is Plague Doctor ? The smalltalkhub description does not help at all, what is that "window plague" ? > >> On Fri, Jan 30, 2015 at 1:28 PM, stepharo <stepharo(a)free.fr> wrote: >> :) >> >> Great picture! I love Plague Doctor >> freaking guy. >> >> Stef >> >> Le 30/1/15 11:29, Roberto Minelli a Ã©crit : >>> To follow Stefâs advice of advertising our projects, here is the Plague Doctor! >>> >>> During development your Pharo IDE will quickly become overcrowded with unused windows. The Plague Doctor is a tool, inspired by Autumn Leaves, that helps you to mitigate this issue by closing the windows that you are less likely to use in the future. >>> >>> If you want to try our prototype, please install it with the following script or ask me for a quick demo (I am Lille for the PharoDays!). >>> >>> Gofer new >>> smalltalkhubUser: 'RobertoMinelli' project: 'PlagueDoctor'; >>> package: 'ConfigurationOfPlagueDoctor'; >>> load. >>> (Smalltalk at: #ConfigurationOfPlagueDoctor) loadDevelopment. >>> >>> <mime-attachment.png> >>> >>> http://smalltalkhub.com/#!/~RobertoMinelli/PlagueDoctor >>> >>> P.s. If you report a problem or a feature request, please file in an entry >>> https://github.com/RobertoMinelli/PlagueDoctor/issues >

Jan. 30, 2015

Re: [Pharo-dev] Fwd: 14827 ProtoObject>>pointersTo failing circular references

by Ben Coman

Yes. I just got back to looking at it and noticed the culprit was printString. Now #printString --> #printStringLimitedTo: --> #streamContents:limitedTo: which uses LimitedWriteStream that should protect against such recursion. However Array>>printOn: is... self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: aStream. ^ self]. self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: aStream. ^ self]. super printOn: aStream where #shouldBePrintedAsLiteral and #isSelfEvaluating recursively call themselves - bypassing the protection of LimitedWriteStream. As an aside, Array>>shouldBePrintedAsLiteral seems identical to Array>>isLiteral -- so is it redundant and the former be deprecated? Now I don't quite follow the semantics of #isLiteral and #isSelfEvaluating for Arrays. a := #( 1 2 { 3 . 4 } 5). a isLiteral. "true" a isSelfEvaluating. "true" b := { 1 . 2 . #( 3 4 ) . 5 }. b isLiteral. "true" b isSelfEvaluating. "true" So can someone provide an example for an Array where #isLiteral or #isSelfEvaluating are false ? Otherwise it seems it will always take the first condition of Array>>printOn: . cheers -ben On Fri, Jan 30, 2015 at 9:23 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > Quick and Dirty, > replace Array>>#printOn: > with > > printOn: aStream > self class = Array ifTrue: [self printAsSelfEvaluatingFormOn: aStream. > ^ self]. > super printOn: aStream > > testObject := 'TEST'. > ref1 := { testObject. nil }. > ref2 := { ref1 }. > ref3 := { ref2 }. > ref1 at: 2 put: ref3. "note the reference loop this creates" > testObject pointersTo asString > > works > > > 2015-01-30 14:15 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> Hi Ben, >> >> i don't know exactly what is happening here, but (size vs. inpsect) >> >> testObject := 'TEST'. >> ref1 := { testObject. nil }. >> ref2 := { ref1 }. >> ref3 := { ref2 }. >> ref1 at: 2 put: ref3. "note the reference loop this creates" >> testObject pointersTo size >> -> 5 >> >> >> >> works. So, the problem is not in #pointersTo but inspecting the result >> array has one or more recursive self calls >> to its elements. >> >> >> >> >> 2015-01-30 3:59 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> I am revisiting my PointerDetective tool, which relies heavily on >>> ProtoObject>>pointersTo. >>> >>> The example I recorded at the repository home page is currently locking >>> & crashing the image due to #pointersTo being unable to handle the circular >>> reference. This "must" have been working on Windows at least around August >>> 2014, but I've been unable to reproduce a working case since my Windows >>> laptop died and I've since moved to OSX. >>> >>> On OSX, in a fresh image 40467 and latest vm 402, the following crashes >>> the image... >>> >>> testObject := 'TEST'. >>> ref1 := { testObject. nil }. >>> ref2 := { ref1 }. >>> ref3 := { ref2 }. >>> ref1 at: 2 put: ref3. "note the reference loop this creates" >>> testObject pointersTo inspect. >>> >>> OSX Memory Monitor shows memory usage shoot from 50MB to >500MB in a few >>> seconds, then usually the image crashes, but sometimes just hangs. >>> >>> I've logged... >>> https://pharo.fogbugz.com/default.asp?14827 >>> >>> cheers -ben >>> >>> >> >

Jan. 30, 2015

Re: [Pharo-dev] Create window group for Playground

by Torsten Bergmann

>Peter UhnÃ¡k >It's still a regular window, so it's possible, the only difference is missing button for it, which according to Tudor was removed purposefully. >Â >http://forum.world.st/GT-Playground-Inspect-window-menu-tp4782020p4782044.h… Looks like I missed this thread. Tudor comment is a little bit funny there: "by default in Morphic every window gets the generic menu that nobody really uses,". When he does not use it it does not mean that all other do not use it ;) I like when we make progress - but we should also take care not to constantly break others flow. I also currently circumvent the missing functionality the same way as Kilon describes: by opening an old workspace first, switching to grouping and dragging the playgrounds there. Please can we have this grouping back somehow. I dont care about the window menu itself but the grouping avoids the windows hell and we should get this back. In the long term I envision that I can drag windows (like playgrounds or Nautilus) onto each other and when I do this long enough they will group automagically. Bye T. Â

Jan. 30, 2015

Re: [Pharo-dev] Fwd: 14827 ProtoObject>>pointersTo failing circular references

by Nicolai Hess

Quick and Dirty, replace Array>>#printOn: with printOn: aStream self class = Array ifTrue: [self printAsSelfEvaluatingFormOn: aStream. ^ self]. super printOn: aStream testObject := 'TEST'. ref1 := { testObject. nil }. ref2 := { ref1 }. ref3 := { ref2 }. ref1 at: 2 put: ref3. "note the reference loop this creates" testObject pointersTo asString works 2015-01-30 14:15 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > Hi Ben, > > i don't know exactly what is happening here, but (size vs. inpsect) > > testObject := 'TEST'. > ref1 := { testObject. nil }. > ref2 := { ref1 }. > ref3 := { ref2 }. > ref1 at: 2 put: ref3. "note the reference loop this creates" > testObject pointersTo size > -> 5 > > > > works. So, the problem is not in #pointersTo but inspecting the result > array has one or more recursive self calls > to its elements. > > > > > 2015-01-30 3:59 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> >> I am revisiting my PointerDetective tool, which relies heavily on >> ProtoObject>>pointersTo. >> >> The example I recorded at the repository home page is currently locking & >> crashing the image due to #pointersTo being unable to handle the circular >> reference. This "must" have been working on Windows at least around August >> 2014, but I've been unable to reproduce a working case since my Windows >> laptop died and I've since moved to OSX. >> >> On OSX, in a fresh image 40467 and latest vm 402, the following crashes >> the image... >> >> testObject := 'TEST'. >> ref1 := { testObject. nil }. >> ref2 := { ref1 }. >> ref3 := { ref2 }. >> ref1 at: 2 put: ref3. "note the reference loop this creates" >> testObject pointersTo inspect. >> >> OSX Memory Monitor shows memory usage shoot from 50MB to >500MB in a few >> seconds, then usually the image crashes, but sometimes just hangs. >> >> I've logged... >> https://pharo.fogbugz.com/default.asp?14827 >> >> cheers -ben >> >> >

Jan. 30, 2015