- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] compiledcode ?

by ClÃ©ment Bera

I will do a slice today. On Mon, May 23, 2016 at 12:49 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Would it be possible to add some comments, please. > > CompiledMethod is now a subclass of the new class CompiledCode (and there > is another > class CompiledBlock). > > Can we please don't add new classes at this system level without *any* > comment. > > nicolai >

May 23, 2016

compiledcode ?

by Nicolai Hess

Would it be possible to add some comments, please. CompiledMethod is now a subclass of the new class CompiledCode (and there is another class CompiledBlock). Can we please don't add new classes at this system level without *any* comment. nicolai

May 22, 2016

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

by Alexandre Bergel

Very right! I should have guessed this. Thanks! Cheers, Alexandre > On May 22, 2016, at 3:46 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 22, 2016

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

by Henrik Nergaard

If the cursor uses a solid fill (color) only it should be redrawn, and when it blinks "off" only the RubScrolledTextMorph (if it has a solid fill), and any of it submorphs which intersects with the damage area should be redrawn. (drawing is being called for the full window) The only area modified is that within the clipping rect of the canvas (damaged area). For non-complex drawing (system window only draws a rectangle with border) filling over a small area should not be noticeable performance wise (as long as the submorph tree is not too deep), but should be fixed. I think the best place to start looking at and improving is in WorldState >>#drawWorld:submorphs:invalidAreasOn: 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 9:50 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] weird tales about cursors and rectangle invalidations Hi, flash damaged areas is not showing me anything :( but still, you seems to be in agreement with me and what is happening *should not* happen, isnât? (drawing is being called for the full window) btw, this is not just a rubric problem, it happens if I put a PluggableTextMorph as well. cheers! Esteban > On 22 May 2016, at 21:28, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > 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] weird tales about cursors and rectangle invalidations

by Henrik Nergaard

I thought that they were merged into a larger one. Only if there is significant overlap between a new damage and current recorded damages, or if the amount of invalid rectangles size is >= 50. (see DamageRecorder >>#recordInvalidRect:) -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: Sunday, May 22, 2016 9:49 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] weird tales about cursors and rectangle invalidations Le 22/5/16 Ã 21:28, Henrik Nergaard a Ã©crit : > 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. I thought that they were merged into a larger one. > > 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] From a mooc user: method source with it' take so long in Pharo 5

by stepharo

Fun analysis :) Le 22/5/16 Ã 17:26, Eliot Miranda a Ã©crit : > 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 > <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] *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 stepharo

tx Le 22/5/16 Ã 17:17, Eliot Miranda a Ã©crit : > 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

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

by Cyril Ferlicot D.

Le 22/05/2016 21:49, Esteban Lorenzano a Ã©crit : > Hi, > > flash damaged areas is not showing me anything :( > but still, you seems to be in agreement with me and what is happening *should not* happen, isnât? (drawing is being called for the full window) > > btw, this is not just a rubric problem, it happens if I put a PluggableTextMorph as well. > Hi, I tried to make a stdout on the drawOn: of FastTable and let the text area blink but there was no new lines on the stdout. So it seems that the lists from Nautilus are not updated when the cursor blink. > cheers! > Esteban > > > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

May 22, 2016

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

by stepharo

Le 22/5/16 Ã 20:44, Esteban Lorenzano a Ã©crit : >> 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. yes > 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) This is why I started also to add methods iconNamed: aSymbol Smalltalk ui icons aSymbol so that we can start to think and it will be easier to produce iconNamed: aSymbol Icon fromSymbol: aSymbol I HATE so much these bad bad bad global variable idea. I think that this pattern is doomed. We should have an object This is the same for Smalltalk tools browser Why the clients cannot get initialized with a tool context registry and the code would be registry browser We are accepting not so good design to my opinion and we are getting spaghetti. Stef >> >> and the class knows how to fetch it? >> >> > >

May 22, 2016

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

by Esteban Lorenzano

Hi, flash damaged areas is not showing me anything :( but still, you seems to be in agreement with me and what is happening *should not* happen, isnât? (drawing is being called for the full window) btw, this is not just a rubric problem, it happens if I put a PluggableTextMorph as well. cheers! Esteban > On 22 May 2016, at 21:28, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > 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