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

Re: [Pharo-dev] weird tales about cursors and rectangle invalidations

by Henrik Nergaard

Hi Esteban, To see the damage live: SystemSettings->Tools->Debugging->Flash damaged morphic region. Redrawing: Only morphs whose area is within the visible draw region of the canvas (the damaged area) needs to be redrawn, so if a morph fullbounds is not intersecting with this area it will not be drawn, and its submorphs will not check deeper in this submorph hierarchy. The exclusion is done in #fullDrawOn: by "(aCanvas isVisible: self fullbounds) ifFalse: [ ^self ]. So if the cursor reports a damage rectangle only morphs intersecting with that area needs to be redrawn (there is also some layering mechanism IIRC so that it should only re-draw the visible layers in that area, and not morphs which are covered by their submorphs). DamageRecorder: The damage recorder do not know about any layering of morphs when it records damage. This means that if there is two overlapping windows in the World, and the window in the back triggers an invalid area which intersects with the window above, it will have to be redraw for that area as well even though it is not necessary. There is also the issue where multiple small areas close to each other need multiple passes to be completed. If the damage recorder has damage in (10@10 corner: 20@20) and (10@30 corner: 20@40) a morph with bounds (0@0 corner: 50@50) will be redrawn twice during that cycle. Rubric: There is some issues with how rubric handle changes, which causes blinking the cursor to do way to much work that it actually have to do, I think it also invalidates the whole selection and needs to redraw that as well. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano Sent: Sunday, May 22, 2016 8:36 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: [Pharo-dev] weird tales about cursors and rectangle invalidations Hi, Iâve been playing a bit today with something that is puzzling me and I need some more eyes in what Iâm doing, because it might be that Iâm understanding everything wrongâ¦ but if not, then, huston, we have a bug. So, play with meâ¦ you need to create this: SystemWindow subclass: #XSystemWindow instanceVariableNames: 'iteration' classVariableNames: '' package: âXXX' XSystemWindow>>initialize super initialize. iteration := 0. XSystemWindow>>drawOn: aCanvas âDo not use transcript because it does even more crazy stuff" Stdio stdout << (iteration := iteration + 1) asString; cr; lf. super drawOn: aCanvas Then execute this in a playground: XSystemWindow new addMorph: (RubScrolledTextModel new newScrolledText) fullFrame: LayoutFrame identity; openInWorld. and then you can watch in your stdout how full window redraws with cursor blinking (it stops when window loses focus). This happens because cursor is displayed with lapsus of 700ms and is just a draw of a line with a color who is set to itâs opposite each time. Then it does "color: shownColorâ and #color: sends #changed who finalise in #invalidRect. I always thought that this invalidation mechanism works by recording âdamaged areasâ, then collecting morphs with that area and triggering the redraw of that morph. With this in mind, cursor should trigger an invalidation of itâs own area (a small portion of the screen, as you can see). I could understand that a cursor triggers the text area redraw (but that would be a âdesign flawâ, IMO)â¦ now, what I cannot understand is why blink a cursor triggers the redraw of a FULL WINDOW. When in Nautilus, that means each cursor blink triggers the redraw of one tree, four lists, some buttons and finally, the text area. IMO, this is not acceptable. What do you think? Esteban

May 22, 2016

Re: [Pharo-dev] Turning off Spotter using internet!

by Alistair Grant

Hi Sven, On Thu, May 19, 2016 at 08:42:36PM +0200, Sven Van Caekenberghe wrote: > > > On 19 May 2016, at 19:36, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > On Thu, May 19, 2016 at 01:53:04PM +0200, Sven Van Caekenberghe wrote: > >> > >>> On 19 May 2016, at 13:41, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> Hi guys > >>> > >>> This is hyper annoying that Spotter look for the net by default. > >>> > >>> We should turn it off. > >> > >> This was 'fixed' in the sense that it now only gets it once every 24 > >> hours and then caches it in the image. > >> > >> The real problem is that NetNameResolver (dns name -> IP address > >> resolution, using of course opaque primitives) sometimes hangs. This > >> makes it very hard for the image to decide if it has network > >> connection or not. And thus hard to react in an intelligent way. > >> > >> This situation is also hard to debug, because if I turn off my > >> wireless network, NetNameResolver fails immediately (which is > >> perfect). It is hard to reproduce the case where it hangs, at least > >> for me. > > > > I think this can be "easily" reproduced by leaving Pharo running while > > switching networks. > > > > I haven't tested this explicitly, but my working assumption at the > > moment is that if I suspend my laptop with Pharo running and connect to > > a different network then Pharo will hang on the first network access. > > I do this every day twice (home > work > home) and it never fails. > > > I'll try and track this down further if someone wants. > > Yes please, but include details (platform, OS, versions). My apologies for the slow reply, it has been a busy few days, and will continue for the next few. I'll try and track this down further. FYI: OS: Arch Linux (4.5.4-1-ARCH) Pharo 5.0 various beta versions since early April, currently on 50757. Cheers, Alistair

May 22, 2016

Re: [Pharo-dev] Using the stack and garbage collector?

by Sven Van Caekenberghe

15000! is a huge number, this computation involves large integer arithmetic. Large integers are allocated on the heap. Try a small number (to stay within Small integer range) and you'll see there is no GC activity. BTW, the implementation of #factorial is not the correct algorithm when speed and efficient large integer arithmetic are required. Please use the pharo-user ML for these kind of general questions. > On 22 May 2016, at 20:12, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > > The following expression give me 102: > -=â=-=-=â=-=-=â=-=-=â=-= > old := Smalltalk vm parameterAt: 9. > 15000 factorial. > new := Smalltalk vm parameterAt: 9. > new - old > -=â=-=-=â=-=-=â=-=-=â=-= > > I find that surprising. Why is the garbage collector used if factorial solely use the stack? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

May 22, 2016

Re: [Pharo-dev] About Smalltalk ui icons...

by Esteban Lorenzano

> On 22 May 2016, at 17:51, stepharo <stepharo(a)free.fr> wrote: > > loadConfigurationButton: aList > <menu> > aList > act: [ :presenter | self onLoadFrom: presenter ] > icon: Smalltalk ui icons configIcon > entitled: 'Load configuration (do not install project)' > > > why we could not have something like > > loadConfigurationButton: aList > <menu> > aList > act: [ :presenter | self onLoadFrom: presenter ] > icon: #configIcon > entitled: 'Load configuration (do not install project)â in this case it should be called #act:iconNamed:entitled:, IMO. but I was thinking and what I actually would do is to model the class Icon, and then you can add an extension to symbol â#asIconâ who call some "Icon fromSymbol: blah" then the strategy of resolution can change without changing anything in the system :P (I know you would not like #asIcon, but I think in this case it would be better than all those "Smalltalk ui icons iconNamed: blah" all around the image) > > > and the class knows how to fetch it? > >

May 22, 2016

weird tales about cursors and rectangle invalidations

by Esteban Lorenzano

Hi, Iâve been playing a bit today with something that is puzzling me and I need some more eyes in what Iâm doing, because it might be that Iâm understanding everything wrongâ¦ but if not, then, huston, we have a bug. So, play with meâ¦ you need to create this: SystemWindow subclass: #XSystemWindow instanceVariableNames: 'iteration' classVariableNames: '' package: âXXX' XSystemWindow>>initialize super initialize. iteration := 0. XSystemWindow>>drawOn: aCanvas âDo not use transcript because it does even more crazy stuff" Stdio stdout << (iteration := iteration + 1) asString; cr; lf. super drawOn: aCanvas Then execute this in a playground: XSystemWindow new addMorph: (RubScrolledTextModel new newScrolledText) fullFrame: LayoutFrame identity; openInWorld. and then you can watch in your stdout how full window redraws with cursor blinking (it stops when window loses focus). This happens because cursor is displayed with lapsus of 700ms and is just a draw of a line with a color who is set to itâs opposite each time. Then it does "color: shownColorâ and #color: sends #changed who finalise in #invalidRect. I always thought that this invalidation mechanism works by recording âdamaged areasâ, then collecting morphs with that area and triggering the redraw of that morph. With this in mind, cursor should trigger an invalidation of itâs own area (a small portion of the screen, as you can see). I could understand that a cursor triggers the text area redraw (but that would be a âdesign flawâ, IMO)â¦ now, what I cannot understand is why blink a cursor triggers the redraw of a FULL WINDOW. When in Nautilus, that means each cursor blink triggers the redraw of one tree, four lists, some buttons and finally, the text area. IMO, this is not acceptable. What do you think? Esteban

May 22, 2016

Using the stack and garbage collector?

by Alexandre Bergel

Hi! The following expression give me 102: -=â=-=-=â=-=-=â=-=-=â=-= old := Smalltalk vm parameterAt: 9. 15000 factorial. new := Smalltalk vm parameterAt: 9. new - old -=â=-=-=â=-=-=â=-=-=â=-= I find that surprising. Why is the garbage collector used if factorial solely use the stack? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 22, 2016

About Smalltalk ui icons...

by stepharo

loadConfigurationButton: aList <menu> aList act: [ :presenter | self onLoadFrom: presenter ] icon: Smalltalk ui icons configIcon entitled: 'Load configuration (do not install project)' why we could not have something like loadConfigurationButton: aList <menu> aList act: [ :presenter | self onLoadFrom: presenter ] icon: #configIcon entitled: 'Load configuration (do not install project)' and the class knows how to fetch it?

May 22, 2016

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

by Esteban Lorenzano

> On 22 May 2016, at 17:26, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Henrik, > > cc'ing squeak-dev cuz this is relevant to both communities (if and until Pharo takes the unwise decision to double the size of the image by keeping sources in the image). this will not happen :) yes, we have played with the idea, but at the end we have some good reasons to not do itâ¦ but by the way, it was not âdoublingâ because what we were keeping was a compressed version. What weâll probably do is to change the file format to a real hash database for sources (like CDB, or something) and to epicea for changes (because epicea can store full refactor histories, etcâ¦)â¦ but this format migration is still very green, we need first to extract the functionality and decouple it (because now read/write is scattered all over the image). > > On May 22, 2016, at 5:01 AM, Henrik Nergaard <henrik.nergaard(a)uia.no <mailto:henrik.nergaard@uia.no>> wrote: > >> There is a method in SourceFileArray #localProcessReadStreamAtFileIndex:atPosition:ifPresent:ifAbsent: which uses a ProccessLocalVariable called ProccessAndSessionLocalSourcesFileArray (see #localProcessReadOnlyCopy). Changing the last line in #readStreamAt:ifPresent:ifAbsent: to use this local process one makes the time to run this snippet: >> >> [ 1 systemNavigation browseMethodsWithSourceString: 'Morph' matchCase: false ] timeProfile >> >> From ~ 10 seconds to ~ 3 seconds (Windows). >> >> However I cannot see that the file handles created by this processLocalVariable to ever be closed, so I suspect those are leaked? In that case there might be the need to implement some âclean upâ mechanism for ProccessLocalVariables before they are changed/nilled when a process changes. >> >> Another approach could be to not use a ProccessLocalVariabe at all, but extend the SourceFilesArray class to also hold one read only handle for each of its files, and use these in readStreamAtFileIndex:::â¦ . I guess that it is also necessary then to have semaphore protecting the two last lines such that setting the position in the stream and reading from it cannot be changed by other threads. > > I like this approach, but it has a fatal flaw. If one is debugging file access, then as the debugger causes the source of methods to be fetched as the debugger displays them, so the file pointer in the read-only file the access of which one is trying to debug will change under one's feet, and the results will be completely wrong. > > An approach which uses a special copy for the debugger doesn't work; one can't debug access to that file for the same reason. > > An approach that /should/ work is for the debugger to install its own copy around file-access. This should be recursive. So around every file access in the debugger there would need to be something like > > SourceFiles substituteFreshReadOnlyCopiesDuring: [...file access...] > > which would remember the current read-only files, evaluate the block using ensure: and have the ensure: block reinstall the previous file. > > Does this make sense? > >> >> readStreamAtFileIndex: index atPosition: position ifPresent: presentBlock ifAbsent: absentBlock >> >> | stream result| >> stream := self readOnlyFileAt: index. >> stream ifNil: [ ^ absentBlock value ]. "sources file not available" >> >> position > stream size ifTrue: [ ^ absentBlock value ]. >> >> readSema critical: [ >> stream position: position. >> result := presentBlock value: stream >> ]. >> >> ^ result >> >> >> Best regards, >> Henrik >> >> >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>] On Behalf Of Nicolai Hess >> Sent: Thursday, May 19, 2016 9:31 AM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> >> Subject: Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5 >> >> Squeak caches the opened readonly file(handle). It does not have to reopen the file on every call for reading (readonly). >> >> 2016-05-18 19:12 GMT+02:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: >> I am wondering why does the search 'method source with it' take so long in Pharo 5? On my PC, When I select the text 'menu' and search for all 'method source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 seconds. >>

May 22, 2016

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

by Eliot Miranda

Hi Henrik, cc'ing squeak-dev cuz this is relevant to both communities (if and until Pharo takes the unwise decision to double the size of the image by keeping sources in the image). > On May 22, 2016, at 5:01 AM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > There is a method in SourceFileArray #localProcessReadStreamAtFileIndex:atPosition:ifPresent:ifAbsent: which uses a ProccessLocalVariable called ProccessAndSessionLocalSourcesFileArray (see #localProcessReadOnlyCopy). Changing the last line in #readStreamAt:ifPresent:ifAbsent: to use this local process one makes the time to run this snippet: > > [ 1 systemNavigation browseMethodsWithSourceString: 'Morph' matchCase: false ] timeProfile > > From ~ 10 seconds to ~ 3 seconds (Windows). > > However I cannot see that the file handles created by this processLocalVariable to ever be closed, so I suspect those are leaked? In that case there might be the need to implement some âclean upâ mechanism for ProccessLocalVariables before they are changed/nilled when a process changes. > > Another approach could be to not use a ProccessLocalVariabe at all, but extend the SourceFilesArray class to also hold one read only handle for each of its files, and use these in readStreamAtFileIndex:::â¦ . I guess that it is also necessary then to have semaphore protecting the two last lines such that setting the position in the stream and reading from it cannot be changed by other threads. I like this approach, but it has a fatal flaw. If one is debugging file access, then as the debugger causes the source of methods to be fetched as the debugger displays them, so the file pointer in the read-only file the access of which one is trying to debug will change under one's feet, and the results will be completely wrong. An approach which uses a special copy for the debugger doesn't work; one can't debug access to that file for the same reason. An approach that /should/ work is for the debugger to install its own copy around file-access. This should be recursive. So around every file access in the debugger there would need to be something like SourceFiles substituteFreshReadOnlyCopiesDuring: [...file access...] which would remember the current read-only files, evaluate the block using ensure: and have the ensure: block reinstall the previous file. Does this make sense? > > readStreamAtFileIndex: index atPosition: position ifPresent: presentBlock ifAbsent: absentBlock > > | stream result| > stream := self readOnlyFileAt: index. > stream ifNil: [ ^ absentBlock value ]. "sources file not available" > > position > stream size ifTrue: [ ^ absentBlock value ]. > > readSema critical: [ > stream position: position. > result := presentBlock value: stream > ]. > > ^ result > > > Best regards, > Henrik > > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Nicolai Hess > Sent: Thursday, May 19, 2016 9:31 AM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5 > > Squeak caches the opened readonly file(handle). It does not have to reopen the file on every call for reading (readonly). > > 2016-05-18 19:12 GMT+02:00 stepharo <stepharo(a)free.fr>: > I am wondering why does the search 'method source with it' take so long in Pharo 5? On my PC, When I select the text 'menu' and search for all 'method source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 seconds. > > >

May 22, 2016

Re: [Pharo-dev] From a mooc user: method source with it' take so long in Pharo 5

by Eliot Miranda

Hi Steph, almost certainly because in Pharo the sources file is opened once for each method whereas in squeak a read-only copy is taken and reused. I don't like the squeak approach: CurrentReadOnlySourceFiles cacheDuring: [...] but it does play well with the debugger. So fixing this elegantly is non-trivial. I suggest you try and real squeak-dev messages talking about CurrentReadOnlySourceFiles and "read-only copies" of the sources files. _,,,^..^,,,_ (phone) > On May 18, 2016, at 10:12 AM, stepharo <stepharo(a)free.fr> wrote: > > I am wondering why does the search 'method source with it' take so long in Pharo 5? On my PC, When I select the text 'menu' and search for all 'method source with it', in Squeak 5 it takes 3 seconds. In Pharo 5 it takes 21 seconds. > >

May 22, 2016